Re: ghc 4.08 under Win98 [was: Re: ghc 4.08 under WinNT]
>* Setting TMPDIR to a path with a drive letter works, no need to
> edit the Perl driver. Without a drive letter, Perl/Bash/Cygwin
> seems to forget the drive and/or the location of the tmp dir.
My experiments suggested that bash and perl were independently stripping
out any drive letters I put into TMPDIR..., e.g.
export TMPDIR=C:/tmp
perl -e 'print $ENV{"TMPDIR"} . "\n";' # or whatever the syntax is; I'm
# no Perl wizard
resulted in:
/tmp
>* OK, so I've tried a simple HelloWorld app next, but failed
> immediately again: The resulting main.exe can't find HSSTD.DLL.
> Where is it searching? How can I find that out from an .exe?
> How can I set the DLL search path at compilation time? Things
> I definitely knew in the past, but happily forgot.
The search order for DLLs is specified at run-time, and detailed in MSDN,
but goes something like:
1. System "built-in" DLLs.
2. Directory the executable was run from
3. System path (WINNT/ &c.).
4. Current directory (hell security!)
5. PATH
> Main.o(.text+0x1c):fake: undefined reference to
>`_imp__PrelBase_unpackCStringzh_closure'
> Main.o(.text+0x20):fake: undefined reference to
>`_imp__PrelIO_putStrLn_closure'
> Main.o(.text+0x3a):fake: undefined reference to `_imp__stg_gc_enter_1'
> Main.o(.text+0x3f):fake: undefined reference to `_imp__upd_frame_info'
> Main.o(.text+0x66):fake: undefined reference to
>`_imp__PrelBase_unpackCStringzh_closure'
> Main.o(.text+0x8e):fake: undefined reference to `_imp__stg_gc_enter_1'
> Main.o(.text+0x93):fake: undefined reference to `_imp__CAF_BLACKHOLE_info'
> Main.o(.text+0x9b):fake: undefined reference to `_imp__IND_STATIC_info'
> Main.o(.text+0xb1):fake: undefined reference to `_imp__upd_frame_info'
> Main.o(.text+0xd9):fake: undefined reference to
>`_imp__PrelIO_putStrLn_closure'
> collect2: ld returned 1 exit status
Yup, this ain't gonna work.
> At least Cygwin didn't crash my Win98 box, which it easily does after
> emitting some obscure error messages when -split-objs is given to GHC
> for large files. I forgot the exact text of the messages, but cut'n'paste
> is a little bit hard when your box is thrashing and about to die in the
> next 3 seconds.
Don't *ever* use -split-objs on Windows. I never had a crash as a result,
but I had major thrashing. Don't even think about building DLLs this way,
it's horrible.
--
http://sc3d.org/rrt/ | Si hoc legere scis nimium eruditionis habes.
ghc 4.08 under Win98 [was: Re: ghc 4.08 under WinNT]
I've just tried to fix that stub file problem on Win98 and now I'm even more confused: * Setting TMPDIR to a path with a drive letter works, no need to edit the Perl driver. Without a drive letter, Perl/Bash/Cygwin seems to forget the drive and/or the location of the tmp dir. * OK, so I've tried a simple HelloWorld app next, but failed immediately again: The resulting main.exe can't find HSSTD.DLL. Where is it searching? How can I find that out from an .exe? How can I set the DLL search path at compilation time? Things I definitely knew in the past, but happily forgot. * Cunningly I've tried -static then, but linking failed with: Main.o(.text+0x1c):fake: undefined reference to `_imp__PrelBase_unpackCStringzh_closure' Main.o(.text+0x20):fake: undefined reference to `_imp__PrelIO_putStrLn_closure' Main.o(.text+0x3a):fake: undefined reference to `_imp__stg_gc_enter_1' Main.o(.text+0x3f):fake: undefined reference to `_imp__upd_frame_info' Main.o(.text+0x66):fake: undefined reference to `_imp__PrelBase_unpackCStringzh_closure' Main.o(.text+0x8e):fake: undefined reference to `_imp__stg_gc_enter_1' Main.o(.text+0x93):fake: undefined reference to `_imp__CAF_BLACKHOLE_info' Main.o(.text+0x9b):fake: undefined reference to `_imp__IND_STATIC_info' Main.o(.text+0xb1):fake: undefined reference to `_imp__upd_frame_info' Main.o(.text+0xd9):fake: undefined reference to `_imp__PrelIO_putStrLn_closure' collect2: ld returned 1 exit status At least Cygwin didn't crash my Win98 box, which it easily does after emitting some obscure error messages when -split-objs is given to GHC for large files. I forgot the exact text of the messages, but cut'n'paste is a little bit hard when your box is thrashing and about to die in the next 3 seconds. Although I'd really like to make a compatibility release for HOpenGL, personally I declare Windows deprecated for now and switch back to Diablo II... Frustrated, Sven
Profiling
I've just finished a small compiler in Haskell. It nevertheless uses too much memory. I tried to use profiling facilities in ghc - ran ghc over all sources with -prof -auto-all, afterwards ran the program with +RTS -h etc. I've got a plot, which said that the memory is mainly allocated in function genCode, which generates code. I'd like to know what part of the function causes the trouble - there are many subfunctions (it looks like genCode = gc progels where f1 = .. f2 =... etc). I ran program with +RTS -hD - to see what clutters the memory. The plot was nice, some colours where attributed to a closures, but there was no note of closure name at colour box which was dominant on the plot. When I used -hY there was just a little empty square at the same colour box. What does it mean? How to find what eats the memory? Wojciech Moczydlowski, Jr
