- Glasgow-haskell-users

package for ghci
by S.D.Mechveliani 31 May '01

31 May '01

To my question on packages for ghci Simon Marlow <simonmar(a)microsoft.com> responds >> 5. ar -q libHSfoo.a *.o >> ld -r --whole-archive libHSdocon.a -o libHSdocon.o > Here's your problem: you named the output libHSdocon.o, but GHCi is > looking for HSfoo.o (because that's the name you gave in the package > spec). > > ld -r --whole-archive libHSfoo.a -o libHSfoo.o > > [..] Thank you. The matter was indeed in the name. And it was due to the `lib' prefix, not due to `docon'. Because there was a typo in my letter: ...--whole-archive libHSfdocon.a ... while in real experiment it was ...--whole-archive libHSfoo.a ... And I doubt whether the GHC implementation agrees at this point with the GHC User's guide. Section 4.11.2 says ---------------------------------------------- A package specification looks like this: Package {name = "mypkg" hs_libraries = ["HSmypkg"] ... } ... hs_libraries A list of libraries containing Haskell code for this package, with the .a or .dll suffix omitted. On Unix, the `lib' prefix is also omitted. extra_libraries ... ---------------------------------------------- The user (myself) thinks at this: "HSmypkg" in package specification --> <prefix?>HSmypkg.a <prefix?>HSmypkg.o in the library directory. But " `lib' is also omitted " - similarly as `.a'. Hence, the library directory should contain libHSmypkg.a libHSmypkg.o Now, ghci -package-mypkg sees "HSmypkg" in package specification but searches for the file HSmypkg.o. It adds `.o', but skips `lib'. On the other hand, `.o' has different status, it is separated by period. So I wonder. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Poll: System.exitWith behaviour
by Simon Marlow 30 May '01

30 May '01

The current behaviour of System.exitWith doesn't really make sense in a concurrent environment. The current semantics is to: - halt the current thread - run all finalizers (concurrently with any other currently running threads) - stop the system as soon as all finalizers have finished. One high-priority problem we also have is that a program which calls System.exitWith from inside GHCi will shut down the whole system. Here's my current proposal: - introduce a new exception constructor: ExitException ExitCode - System.exitWith causes (ExitException code) to be raised in the current thread. - If this exception propogates to the top of the thread, then the main thread is also sent (ExitException code). This only happens for a standalone executable (ie. one which was started by PrelMain.mainIO). - If this exception propogates to the top of the main thread, then the system is shut down as before - all finalizers are run to completion, then we exit. For GHCi, we can obviously catch the ExitException exception and recover, and there is no main thread in this case. An alternative is just to omit the third point and let the programmer handle propagation of the ExitException to the main thread. This is somewhat consistent with our current policy of leaving these kind of decisions up to the programmer: we currently don't implement any kind of process hierarchy, and there is no requirement for child threads to complete before the program exits, for example. Cheers, Simon

5 5

RE: Evacuated Object
by Simon Marlow 30 May '01

30 May '01

> I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign > function interface (using .hsc files) and the SDL graphics > library (v1.2). > The curious thing is that the following code: > > main = sdlInit [sdlVideo[ > sdlQuit > > can be loaded into GHCi and executed as many times as I like, however, > if I then carry on and edit the module containing main, and > then perform a > reload (:r), I sometimes get an "EVACUATED object entered!" > message and GHC > crashes on me: Great bug! I managed to reproduce it here (except that I get a plain seg fault not a GC panic), and it turns out to be an obscure bug in the native code generator that only shows up with GHCi. Compiling the program with -fvia-C works around it. Many thanks for the report. Cheers, Simon

1 0

RE: package for ghci
by Simon Marlow 30 May '01

30 May '01

> 5. ar -q libHSfoo.a *.o > ld -r --whole-archive libHSdocon.a -o libHSdocon.o Here's your problem: you named the output libHSdocon.o, but GHCi is looking for HSfoo.o (because that's the name you gave in the package spec). True, the documentation doesn't give explicit instructions for building a package from start to finish. I'll add something for a future release. Cheers, Simon

1 0

package for ghci
by S.D.Mechveliani 30 May '01

30 May '01

To my questions on the package creation for ghci -package >> ... >> How should look a package for this? Simon Marlow <simonmar(a)microsoft.com> writes > The "package" consists of libraries, .hi files, and a package > specification. Which bit did you mean? I meant all the three + a whole story of its correct arrangement - to illustrate it on the given example of a single module project. But as you said, my scheme of action in mainly correct. So, let us go further. >> Is it created manually or by ghc -package-name ... ? >> ... >> For I have an impression that the ghc-5.00 User's guide cannot >> help in this situation. > The user's guide says, about -package-name: > > This option is added to the command line when compiling a > module that is destined to be part of package foo. If this > flag is omitted then the default package Main is assumed. > > seems fairly clear to me... which part are you confused about? I expected that the user would not need to (1) move .hi, .o files manually to /t/export, collecting them from all the project directories (2) archivate manually *.o to .a library, (maybe) (3) create manually the structure Package {...}. Note that the application project forces the user to do all this manually to install the project. I hoped -package-name --make would do (1) and (2). This fragment of User's Guide does not reject such hope. > Which parts of the documentation aren't being helpful to you? > [..] It looks that a newbie would not find out the needed order of action: 1. package specification, 2. ghc-pkg ... 3. ghc --make ..., 4. moving files and archivating to library. Does the Guide specify such order? Is it clear from the Guide which of these points can be done automatically? Where it is explained how to create a library .a from *.o ? A naive functional programmer would not know this, maybe, this is a system hacker's territory (?). I may mistake, this is only my impression. >> Then, after creating manually /t/export/libHSfoo.a >> and converting it by >> ld -r --whole-archive libHSfoo.a -o libHSfoo.o >> [..] >> >> it still does not work. ghci -package foo >> yields >> Loading package foo ... can't find .o or .so/.DLL for: HSfoo >> (libHSfoo.so: cannot open shared object file: No such file > It looks like there may be a problem with your package spec. > Could you list the contents of p.txt that you used to create the > package? I would reproduce the whole (short) story. ------------------------------------------------------- /home/mechvel/t/A.hs contains module A where a = 'a' and is one file project to build a package foo to reside in the directory /home/mechvel/t/export/ /home/mechvel/u/Main.hs imitates the user work with the package foo. It contains module Main where import A main = putStr ['b', a, '\n'] 1. Apply ghc-pkg -a < p.txt with p.txt containing Package {name = "foo", import_dirs = ["/home/mechvel/t/export" ], source_dirs = [], library_dirs = ["/home/mechvel/t/export" ], hs_libraries = ["HSfoo"], extra_libraries = ["HSfoo"], include_dirs = [], c_includes = [], package_deps = [], extra_ghc_opts = [], extra_cc_opts = [], extra_ld_opts = [] } 2. Test it with ghc-pkg -l 3. cd ~/t ghc -package-name foo --make A 4. mv *.hi *.o export/ cd export 5. ar -q libHSfoo.a *.o ld -r --whole-archive libHSdocon.a -o libHSdocon.o ----------------------------------------------------------- cd ~/t ghci -package foo ... Loading package std ... linking ... done. Loading package foo ... ghc-5.00.1: can't find .o or .so/.DLL for: HSfoo (libHSfoo.so: cannot open shared object file: No such file or directory) Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghc-5.00.1 compiling with pw32 for win32.
by hooh pxw 30 May '01

30 May '01

Hi, i am new comer/bie. --*PW32 the Posix-over-Win32 layer*-- http://sourceforge.net/projects/pw32 PW32 is primarily C runtime library for Win32 aiming to POSIX compliance. Its main concerns are effeciency and support even for low-end Win9x systems. Also, PW32 is collection of ported software, aiming to be GNU (etc.) distribution for Win32. LGPL. i have no time to test. if this work, tell me. sorry my lazy cut/paste. global funny thing? no *.hi file errors. ignore below message... __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

1 0

building Green Card using ghc-5 continued
by trb＠eastpac.com.au 29 May '01

29 May '01

Oops - there is one more change needed: add -package lang to HC_OPTS in lib/ghc/Makefile I have not tried using it with Hugs. Tim

1 0

RE: creating packages
by Simon Marlow 29 May '01

29 May '01

> Who could, please, consult on the package setting in ghc-5.00.1 > ? > Let the project foo consist of the files /t/A.hs > /t/t1/B.hs, > B import A, > the user work in /u/ and exploit foo in compiling, linking > and interpreting. > > Everything seems to work below, except `ghci -package' > and `ghc -c -package-name foo' > > (ghc-5.00.1 compiled from source for Linux, i386-unknown). > What I do: > > ------------------------------------------------- > * apply ghc --make B; That should be ghc -package-name foo --make B. because you're building modules for package 'foo'. > * move all *.o *.hi files to /t/export/ ; > * command cd /t/export/ > ar -q libHSfoo.a *.o (creating a library) > > * create a file p.txt containing > > Package {name = "foo", > import_dirs = ["/t/export" ], > source_dirs = [], > library_dirs = ["/t/export" ], > hs_libraries = ["HSfoo"], > extra_libraries = [], > include_dirs = [], c_includes = [], > package_deps = [], extra_ghc_opts = [], > extra_cc_opts = [], extra_ld_opts = [] > } > and apply ghc-pkg -a < p.txt > adding a package foo to ghc. > ------------------------------------------------- > > Then, for the user module /u/Main.hs > importing B, > the user commands cd /u; ghc -c -package foo Main.hs > ghc -o run Main.o -package foo > - and it works. > But ghci -package foo > yields > Loading package foo ... can't find .o or .so/.DLL for: HSfoo > (libHSfoo.so: cannot open shared object file: No such file > or directory) GHCi can't load .a files (at the moment). You can build a .o file from a .a file like so (with GNU ld): ld --whole-archive libHSfoo.a -o libHSfoo.o Cheers, Simon

1 0

building Green Card using ghc-5
by trb＠eastpac.com.au 29 May '01

29 May '01

I finally got Green Card 2.01 to build with ghc-5.00 . There are two changes required: * replace all uses of -syslib with -package in src/Makefile * remove src/Pretty.lhs src/FiniteMap.lhs and src/GetOpt.lhs - the latter (redundant) source files upset ghc when it tries to import the same modules from packages. Tim

1 0

creating packages
by S.D.Mechveliani 29 May '01

29 May '01

Who could, please, consult on the package setting in ghc-5.00.1 ? Let the project foo consist of the files /t/A.hs /t/t1/B.hs, B import A, the user work in /u/ and exploit foo in compiling, linking and interpreting. Everything seems to work below, except `ghci -package' and `ghc -c -package-name foo' (ghc-5.00.1 compiled from source for Linux, i386-unknown). What I do: ------------------------------------------------- * apply ghc --make B; * move all *.o *.hi files to /t/export/ ; * command cd /t/export/ ar -q libHSfoo.a *.o (creating a library) * create a file p.txt containing Package {name = "foo", import_dirs = ["/t/export" ], source_dirs = [], library_dirs = ["/t/export" ], hs_libraries = ["HSfoo"], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = [], extra_ghc_opts = [], extra_cc_opts = [], extra_ld_opts = [] } and apply ghc-pkg -a < p.txt adding a package foo to ghc. ------------------------------------------------- Then, for the user module /u/Main.hs importing B, the user commands cd /u; ghc -c -package foo Main.hs ghc -o run Main.o -package foo - and it works. But ghci -package foo yields Loading package foo ... can't find .o or .so/.DLL for: HSfoo (libHSfoo.so: cannot open shared object file: No such file or directory) Then, I added /t/export/libHSdocon.so, but it does not help. Also ghc -c -package-name foo C.hs does not work. May ghc -c -package-name do automatically all this mess with moving .o, .hi files and archivating? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0