- Glasgow-haskell-users

RE: Dynamic linking again
by Simon Marlow 04 Sep '02

04 Sep '02

> > I'm not sure exactly what's going here. RtsAPIDeprec.o > does refer to > > Addr_Azh_con_info, which is defined in the Addr module in the lang > > package. However, RtsAPIDeprec normally isn't linked in, because > > nothing refers to anything in it. > > RtsAPIDeprec.o is in libHSrts.a (as the error message says). > Therefore using libHSrts.a means that you'll get all of > RtsAPIDeprec.o along with it, and therefore need to resolve all > its unresolved symbols. er, no. An object file from a library is only linked in if one of the symbols it exports is required by the main program. So RtsAPIDeprec.o normally isn't linked in. > I think I also understand why using -package doesn't work. I'll > paste in two (cropped) gcc lines below; the first line is when > you use the "-lHSrts -lHSlang" options (which works), and the > second is when you use "-package rts -package -lang" (which > doesn't work): > > ... -L/usr/lib/ghc-5.04 > -L/usr/lib/gcc-lib/i386-linux/3.2 > -L/usr/lib/gcc-lib/i386-linux/3.2/../../.. > Main.o -ldl -lHSlang -lHSlang_cbits > -lHShaskell98 -lHSbase -lHSbase_cbits -lHSrts -lgmp -lm -lgcc > -lgcc_eh -lc -lgcc -lgcc_eh > /usr/lib/gcc-lib/i386-linux/3.2/crtend.o > /usr/lib/gcc-lib/i386-linux/3.2/../../../crtn.o > ... -L/usr/lib/ghc-5.04/ -L/usr/lib/ghc-5.04 > -L/usr/lib/gcc-lib/i386-linux/3.2 > -L/usr/lib/gcc-lib/i386-linux/3.2/../../.. > /usr/lib/ghc-5.04/HSbase.o Main.o -ldl -lHSrts -lHSlang > -lHShaskell98 -lHSbase -lHSbase_cbits -lHSrts -lgmp > -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh > /usr/lib/gcc-lib/i386-linux/3.2/crtend.o > /usr/lib/gcc-lib/i386-linux/3.2/../../../crtn.o > > .. so the only real difference between the line which works and > the line which doesn't work is: > > * line which works has /usr/lib/ghc-5.04/HSbase.o > * line which works has an extra -lHSrts flag Now I'm really confused. Maybe you got these round the wrong way: the "line which works" is the first line according to the first paragraph above, but it doesn't contain /usr/lib/ghc-5.04/HSbase.o, which is in the second line. And where on earth did /usr/lib/ghc-5.04/HSbase.o come from anyway? That must have been specified on the command line too. To link in the whole base package and enable -export-dynamic this works (for me): ghc Foo.o Bar.o .... /path/to/HSbase.o -optl-Wl,export-dynamic > It turns out that the pedant linker needs to see the -lHSrts flag > before -lHSlang. This is a bit odd, since the HSlang library is > the one which has the required "Addr_Azh_con_info" symbol. The RTS has several forward references of this kind. To ensure that this works, we add a number of '-u' options to the linker command line (see the package spec for the 'rts' package). We *don't* do this for the forward references from RtsAPIDeprec, because that would force us to link the lang package every time. RtsAPIDeprec should really go away. In order to use it at all you'd have to go through some contortions to get the linking to work, so I don't imagine anyone is using it. Instead of using the -u options we could use the --start-group and --end-group options of GNU ld, but this is likely to be (a) less portable and (b) slower. Cheers, Simon

2 1

Re: Why it's dangerous to fork off a new process in Glasgow Haskell
by George Russell 04 Sep '02

04 Sep '02

Volker Stolz wrote (about GHC.Conc.forkProcess): [snip] > > Interesting. How exactly does it work, by the way? > > Trade secret ;) Simply drop the TSO pointers to all other threads > from the queues so the RTS won't find them again (GC is a > different issue). Ah I see. The code is in ghc/rts/Schedule.c, in the function forkProcess. > > > Posix.runProcess really should use it I think. > > No, it's better to be able to choose the way to handle this. > Maybe add a flag to Posix.runProcess. But the whole > GHC.Conc.forkProcess isn't finished, yet, anyway. I don't really see the point of allowing the user to choose the old way. Posix.runProcess is supposed to fork off a new process outside of this runtime system. I don't see any way this can be helped by allowing other threads to continue in the child until the actual time of exec, unless for some reason the evaluation of the arguments to exec somehow relies on other threads. But this would surely at least require argument evaluation to unsafely conceal IO, and in any case could be better fixed by forcing the arguments to be fully evaluated before the fork. > > > The signature of Posix.runProcess is not quite adequate though; one wants some control > > over the child thread. At a minimum, it would be nice to be able to kill it. > ^^^^^^^^ > process? > > You still get the child's pid, so feel free to mess with it. You don't get it from Posix.runProcess. Posix.runProcess is supposed to be OS-independent (even though it's only available in Posix) and I'm not sure if a pid makes much sense on Windows anyway. What I think I would like on all systems is a new abstract data type ChildProcess with functions runProcess :: FilePath -> [String] -> Maybe [(String,String)] -> Maybe FilePath -> Maybe Handle -> Maybe Handle -> Maybe Handle -> IO ChildProcess (so the same as Posix.runProcess now except for returning ChildProcess) and killChildProcess :: ChildProcess -> IO () and ideally something like Posix.getProcessStatus as well. This is not completely trivial to implement; for example one would like runProcess to raise some exception if the exec fails, which means passing the information back to the parent in some way. But if you put together Sigbjorn's stuff for Windows and the existing Posix code it shouldn't be too hard.

2 3

Why it's dangerous to fork off a new process in Glasgow Haskell
by George Russell 04 Sep '02

04 Sep '02

I have some code which forks off a new process which does some non-Haskelly stuff. Thus it does the standard things, something like processId <- Posix.forkProcess case processId of Just _ -> -- parent process, continue normally ... Nothing -> -- child process do ... -- rearrange plumbing of stdin/stdout/stderr Posix.executeFile [blah] The GHC runProcess function uses a similar mechanism. Unfortunately this has developed an extremely irritating bug. The problem is that my program has a lot of worker threads which do things like communicating with servers, already running programs, and so on. These worker threads get replicated in the child process (like everything else) which means that you now have two clients communicating with the server, where there ought to be one, result chaos. (Or in this case, the entire program coming to a halt.) I've had this code for several years (I inherited it), but the problem seems to have recently got much worse; I don't know whether this is because of a change in GHC's scheduling with ghc5.04, or because I am now compiling much more complicated programs. Whatever, I simply couldn't find a way of fixing this in Haskell. It would be good if there were a way of telling GHC's RTS scheduler "Please don't run any other threads apart from this one until further notice". If so, you could do [block other threads] [do fork] [if parent process then unblock other threads ... else -- child process rearrange plumbing and do exec ] But there isn't. So in the end I resorted to writing a C function which does both the forking and replumbing and execing. Since GHC doesn't run native threads while foreign C code is executing, this fixes the problem. It would be nice if there were a better way . . .

4 6

RE: Dynamic linking again
by Simon Marlow 04 Sep '02

04 Sep '02

> So here's another idea. ghc's linker provides (via the ffi) a command > addDLL to load dynamic libraries. It uses dlopen on unix and > LoadLibrary on win32. > > Now, with dlopen if you pass it NULL rather than the filename of a > library it will give you back a handle to itself - the program that > called it. If you've linked your program with the right incantations > this gives you access to all the symbols in the main program. Yes, we already use dlopen() with NULL to get symbols from other shared libraries, so you can refer to things like printf() from libc. I didn't know about -export-dynamic: yes, it looks like that would do exactly the right thing. The linker might not even need any modification for this to work, because we already fall back to using dlsym() for a symbol that the linker can't find in its own symbol table. [... I've just tried a simple example using -export-dynamic, and it does indeed work as advertised... ] To like the whole of the base package into the binary, you can either use --whole-archive with libHSbase.a as suggested by Alastair, or link in HSbase.o. Similarly for the haskell98 package. Let us know how you get on... Cheers, Simon

5 8

RE: GHCi off by default?
by Simon Marlow 02 Sep '02

02 Sep '02

> I noticed that when I build ghc-5.04 from source, the > resulting executables > have interactive mode disabled. > > There is some code in mk/config.mk that appears backwards to > me (although > according to the accompanying comment it is not backwards): > > #ifneq "$(findstring $(HostOS_CPP), mingw32 cygwin32 linux > solaris2 freebsd > netbsd openbsd)" "" > GhcWithInterpreter=YES > ifeq "$(HaveLibDL)" "YES" > SRC_HC_OPTS += -ldl > endif > #else > #GhcWithInterpreter=NO > #endif > > This appears to turn GHCi off for mingw32, cygwin32, linux, > solaris2, freebsd, netbsd, and openbsd. No, it's actually on for all these platforms. However, you have to bootstrap the compiler with itself before GHCi will be built (see ghc/compiler/Makefile). Cheers, Simon

2 2

RE: Dynamic linking again
by Simon Peyton-Jones 02 Sep '02

02 Sep '02

| Now, with dlopen if you pass it NULL rather than the filename | of a library it will give you back a handle to itself - the Ah. I didn't know that. | So can anyone poke holes in my grand plan or should I give it a go? Don't forget the issue that the 'main' program might not have all the symbols you need. And remember that you need to persuade GHCi's linker to populate its symbol table with the symbols you how have. Simon

1 0

GHCi off by default?
by Seth Kurtzberg 02 Sep '02

02 Sep '02

Simon, I noticed that when I build ghc-5.04 from source, the resulting executables have interactive mode disabled. There is some code in mk/config.mk that appears backwards to me (although according to the accompanying comment it is not backwards): #ifneq "$(findstring $(HostOS_CPP), mingw32 cygwin32 linux solaris2 freebsd netbsd openbsd)" "" GhcWithInterpreter=YES ifeq "$(HaveLibDL)" "YES" SRC_HC_OPTS += -ldl endif #else #GhcWithInterpreter=NO #endif This appears to turn GHCi off for mingw32, cygwin32, linux, solaris2, freebsd, netbsd, and openbsd. Should that be #ifeq instead of #ifneq? Or am in misinterpreting? -- ----------------------------------- Seth Kurtzberg M. I. S. Corp. 1-480-661-1849

1 0

Problem with Library ObjectIO
by Alfonso Meléndez 01 Sep '02

01 Sep '02

Hello my name is alfonso melendez, haskell user since 1998, actually i am developing a project and i am working with the clean library objectio, my problem is: the setControlLook function apparently does not work with CompoundControl i have tried to create a CompoundControl and I can not t put graphics text on it using the setControlLook function. What I am trying to d o is to create a scrolling box with CompoundControl but it does not work. I appreciate if you can help me With this e -mail I send the code of my program, the line that doesnt work is line 70 ===== Alfonso Meléndez Escuela Colombiana de Ingeniería Centro de Estudios Informáticos tel:6762666 Ext:224 _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es

1 0

Problem with Library ObjectIO
by Alfonso Meléndez 01 Sep '02

01 Sep '02

Hello my name is alfonso melendez, haskell user since 1998, actually i am developing a project and i am working with the clean library objectio, my problem is: the setControlLook function apparently does not work with CompoundControl i have tried to create a CompoundControl and I can not t put graphics text on it using the setControlLook function. What I am trying to d o is to create a scrolling box with CompoundControl but it does not work. I appreciate if you can help me With this e -mail I send the code of my program, the line that doesnt work is line 70 ===== Alfonso Meléndez Escuela Colombiana de Ingeniería Centro de Estudios Informáticos tel:6762666 Ext:224 _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es

1 0

Dynamic linking again
by Duncan Coutts 01 Sep '02

01 Sep '02

So here's another idea. ghc's linker provides (via the ffi) a command addDLL to load dynamic libraries. It uses dlopen on unix and LoadLibrary on win32. Now, with dlopen if you pass it NULL rather than the filename of a library it will give you back a handle to itself - the program that called it. If you've linked your program with the right incantations this gives you access to all the symbols in the main program. So if this method works it would be the easiest way to get plugins working. No need for me to modify ghc (I think)! There do seem to be some problems with using -rdynamic with ghc however: http://www.haskell.org/pipermail/gtkhs/2002-March/000253.html As it is noted, it produces large executibles since all symbols get exported. I've not yet been able to find a way to limit the symbols that are exported. I believe that a similar thing is avaliable on windows since glib's GModule library claims to provide a portable interface for plugins on Linux/Sun HP-UX and Windows. http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html The rightlinker incantations in this case are -rdynamic or perhaps -export-dynamic. So says the man page for ld, though there are some better explanations elsewhere: http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN93 Specifically this bit: In some cases, the call to gcc to create the object file will also need to include the option ``-Wl,-export-dynamic''. Normally, the dynamic symbol table contains only symbols which are used by a dynamic object. This option (when creating an ELF file) adds all symbols to the dynamic symbol table (see ld(1) for more information). You need to use this option when there are 'reverse dependencies', i.e., a DL library has unresolved symbols that by convention must be defined in the programs that intend to load these libraries. For ``reverse dependencies'' to work, the master program must make its symbols dynamically available. Note that you could say ``-rdynamic'' instead of ``-Wl,export-dynamic'' if you only work with Linux systems, but according to the ELF documentation the ``-rdynamic'' flag doesn't always work for gcc on non-Linux systems. So can anyone poke holes in my grand plan or should I give it a go? Duncan

2 1