[MLton] cygwoes
Wesley W. Terpstra
wesley@terpstra.ca
Wed, 5 Oct 2005 13:38:12 +0200
--Apple-Mail-1--118763043
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On Oct 5, 2005, at 2:23 AM, Matthew Fluet wrote:
> Unfortunately, I get a file I/O error if I attempt to complete the
> boostrapping:
>
> $ make constants
> Creating constants file.
> /home/fluet/mlton/mlton.svn.HEAD/build/bin/mlton -build-constants
> true >tmp.c
> openIn /home\fluet\mlton\mlton.svn.head\build\lib/target-map: No
> such file or directory
> make: *** [constants] Error 1
>
> Somehow, my path has been changed to lowercase (it should be
> mlton.svn.HEAD, not mlton.svn.head). I renamed my path to the
> lowercase version, hoping to avoid that issue.
Uhm. Aren't windows filenames case insensitive?
It is getting converted to lower-case because our implementation of
OS.Path lower-cases
everything in compliance with the standard....
"
In a Microsoft Windows implementation, canonical paths are entirely
lowercase.
"
Or is it the case that *cygwin* somehow makes things case dependent?
If so, you need to change basis-library/system/path.sml:
fun canonName a =
- if isWindows
+ if isWindows andalso not volumeHack
then String.translate (str o Char.toLower) a
else a
However, as far as I can recall, cygwin paths are also case
insensitive...?
Looking over the notes I made testing OS.Path, this seems to be the
case.
I don't have cygwin installed at the moment, so I can't check.
Also, your path "/home\fluet\mlton\mlton.svn.head\build\lib/target-
map" looks
broken to me. The first "/" is ok; it is a cygwin specific hack to
get access to the
virtual (fake) filesystem root. However, the last '/' should be a
'\'. Why isn't it?
ie: does "/home\fluet\mlton\mlton.svn.head\build\lib\target-map" work?
Perhaps the parent directory didn't exist?
To sum up:
I think lower-casing is the right thing to do.
I don't understand why it isn't working for you (maybe the later /
is wrong?).
If you need to change it (and violate the standard) above is the
patch to do it.
> Indeed, I'm able to produce the constants .c file, but the system
> call failure seems to be back:
>
> $ make constants
> Creating constants file.
> /home/fluet/mlton/mlton.svn.head/build/bin/mlton -build-constants
> true >tmp.c
> /home/fluet/mlton/mlton.svn.head/build/bin/mlton -output tmp tmp.c
> call to system failed with No child processes:
> gcc -std=gnu99 -c -I/home/fluet/mlton/mlton.svn.head/build/lib/
> include -O1 -fno-strict-aliasing -fomit-frame-pointer -w -fno-
> strength-reduce -fschedule-insns -fschedule-insns2 -malign-
> functions=5 -malign-jumps=2 -malign-loops=2 -o /tmp/fileEZi09z.o tmp.c
It sounds to me like gcc itself is crashing, not mlton.
> Exception: STATUS_ACCESS_VIOLATION at eip=6105B252
> eax=00000000 ebx=00000000 ecx=00000000 edx=10015288 esi=00000000
> edi=10014EA8
> ebp=0022E208 esp=0022E1E0 program=C:\cygwin\bin\gcc.exe, pid 2644,
> thread main
> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
From what (little) I understand of cygwin, I think this is due to
the fork/exec code.
However, do we know which code-path is being used? fork/exec or spawnp?
I think I recall that cygwin uses VirtualFree and Alloc internally to
do mmap, and
tracks the mappings it has created. When it 'fork's, it carefully
copies all the mappings
it knows of into a new process. When exec happens, it carefully
overwrites the
address space.
If you are using VirtualFree/Alloc yourself, it seems reasonable to
suppose that
newer versions of cygwin be confused by the layout of the address
space and
setup gcc with broken/unclean memory. spawnp would not have this
problem.
What was the original reason for avoiding mmap? Does it still apply?
If not, I think it makes most sense to use mmap for cygwin (that way
Posix.Process.fork will also work for MLton users).
To sum up:
I think using VirtualFree/Alloc directly is incompatible with
cygwin fork/exec
So, either: use spawnp and create (ie: useWindowsProcess = true)
or: use mmap everywhere for cygwin
--Apple-Mail-1--118763043
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV><DIV>On Oct 5, 2005, at =
2:23 AM, Matthew Fluet wrote:</DIV><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Unfortunately, I get a file I/O error if I attempt =
to complete the boostrapping:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">$ make constants</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Creating constants file.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">/home/fluet/mlton/mlton.svn.HEAD/build/bin/mlton =
-build-constants true >tmp.c</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">openIn =
/home\fluet\mlton\mlton.svn.head\build\lib/target-map: No such file or =
directory</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">make: *** [constants] Error =
1</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Somehow, my path has been changed to lowercase (it =
should be mlton.svn.HEAD, not mlton.svn.head).<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>I renamed my path to the =
lowercase version, hoping to avoid that =
issue.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>Uhm. Aren't windows filenames =
case insensitive?</DIV><DIV>It is getting converted to lower-case =
because our implementation of OS.Path lower-cases=A0</DIV><DIV>everything =
in compliance with the standard....</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>"</DIV><UL><LI =
style=3D"margin: 0.0px 0.0px 16.0px 0.0px"><FONT =
class=3D"Apple-style-span" face=3D"Times" size=3D"4"><SPAN =
class=3D"Apple-style-span" style=3D"font-size: 16px;">In a Microsoft =
Windows implementation, canonical paths are entirely =
lowercase.</SPAN></FONT></LI></UL><DIV>"</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Or is it the case that =
*cygwin* somehow makes things case dependent?</DIV><DIV>If so, you need =
to change basis-library/system/path.sml:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>=A0 fun canonName a =3D =
</DIV><DIV>- =A0 =A0if isWindows</DIV><DIV>+=A0 =A0if isWindows andalso =
not volumeHack</DIV><DIV>=A0 =A0 =A0=A0 =A0then String.translate (str o =
Char.toLower) a</DIV><DIV>=A0 =A0 =A0else a</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>However, as far as I can =
recall, cygwin paths are also case insensitive...?</DIV><DIV>Looking =
over the notes I made testing OS.Path, this seems to be the =
case.</DIV><DIV>I don't have cygwin installed at the moment, so I can't =
check.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Also,=A0your =
path=A0"/home\fluet\mlton\mlton.svn.head\build\lib/target-map" =
looks</DIV><DIV>broken to me. The first "/" is ok; it is a cygwin =
specific hack to get access to the</DIV><DIV>virtual (fake) filesystem =
root. However, the last '/' should be a '\'. Why isn't it?</DIV><DIV>ie: =
does=A0"/home\fluet\mlton\mlton.svn.head\build\lib\target-map" =
work?</DIV><DIV>Perhaps the parent directory didn't exist?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>To sum up:</DIV><DIV>=A0 I =
think lower-casing is the right thing to do.</DIV><DIV>=A0 I don't =
understand why it isn't working for you (maybe the later / is =
wrong?).</DIV><DIV>=A0 If you need to change it (and violate the =
standard) above is the patch to do it.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Indeed, I'm able to produce the =
constants .c file, but the system call failure seems to be =
back:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">$ make constants</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Creating =
constants file.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">/home/fluet/mlton/mlton.svn.head/build/bin/mlton -build-constants true =
>tmp.c</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">/home/fluet/mlton/mlton.svn.head/build/bin/mlton -output tmp =
tmp.c</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">call to system failed with No =
child processes:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">gcc -std=3Dgnu99 -c =
-I/home/fluet/mlton/mlton.svn.head/build/lib/include -O1 =
-fno-strict-aliasing -fomit-frame-pointer -w -fno-strength-reduce =
-fschedule-insns -fschedule-insns2 -malign-functions=3D5 -malign-jumps=3D2=
-malign-loops=3D2 -o /tmp/fileEZi09z.o tmp.c</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>It sounds to me like gcc =
itself is crashing, not mlton.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Exception: STATUS_ACCESS_VIOLATION at =
eip=3D6105B252</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">eax=3D00000000 ebx=3D00000000 =
ecx=3D00000000 edx=3D10015288 esi=3D00000000 edi=3D10014EA8</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">ebp=3D0022E208 esp=3D0022E1E0 =
program=3DC:\cygwin\bin\gcc.exe, pid 2644, thread main</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">cs=3D001B ds=3D0023 es=3D0023 fs=3D003B gs=3D0000 =
ss=3D0023</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>=46rom what (little) I =
understand of cygwin, I think this is due to the fork/exec =
code.</DIV><DIV>However, do we know which code-path is being used? =
fork/exec or spawnp?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>I think I recall that cygwin =
uses VirtualFree and Alloc internally to do mmap, and<DIV>tracks the =
mappings it has created.=A0When it 'fork's, it carefully copies all the =
mappings=A0</DIV><DIV>it knows of into a new process.=A0When exec =
happens, it carefully overwrites the=A0</DIV><DIV>address space.<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>If you are using =
VirtualFree/Alloc yourself, it seems reasonable to suppose =
that</DIV><DIV>newer versions of cygwin be confused by the layout of the =
address space and</DIV><DIV>setup gcc with broken/unclean memory. spawnp =
would not have this problem.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>What was the original =
reason for avoiding mmap? Does it still apply?</DIV><DIV>If not, I think =
it makes most sense to use mmap for cygwin (that =
way=A0</DIV><DIV>Posix.Process.fork will also work for MLton =
users).</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>To =
sum up:</DIV><DIV>=A0 I think using VirtualFree/Alloc directly is =
incompatible with cygwin fork/exec</DIV><DIV>=A0 So, either: use spawnp =
and create (ie: useWindowsProcess =3D true)</DIV><DIV>=A0 or: use mmap =
everywhere for cygwin</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV></DIV></BODY></HTML>=
--Apple-Mail-1--118763043--