library names of dlopen()ed libraries (GHCi)

Michael Weber michael.weber@post.rwth-aachen.de
Mon, 23 Apr 2001 18:42:50 +0200


Hi!

I'm afraid, there are problems waiting for us with GHCi's way of
loading dynamic libraries.

At first, apologies if I got sth. wrong on dynamic libs (or dlopen()ed,
even).  I'm far from being even remotely informed on that topic, so
everything is `IMHO' implicitly.


1) Why is libm needed by libHSstd?
 Package
     [...] 
     extra_libraries = ["HSstd_cbits", "m"],
     [...]

I removed it and GHCi still worked, i.e. it started and I tested some
commands which (I guess) use libm (e.g. log, isNaN, ...).

After all, ghc is already linked against libm, so why load it
dynamically? (See a) below.)

[204]% ldd /usr/lib/ghc-5.00/ghc-5.00
        libdl.so.2 => /lib/libdl.so.2 (0x4001b000)
-->     libm.so.6 => /lib/libm.so.6 (0x4001f000)                   <--
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40041000)
        libreadline.so.4 => /lib/libreadline.so.4 (0x40063000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x40088000)
        libc.so.6 => /lib/libc.so.6 (0x400c9000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

	
2) From what I was told, dlopen()ing especially _system_ libs is evil
   anyhow. There is no way to determine (via dl*) what ABI version one
   is using, and things will presumeably break, if the SONAME changes.

   BTW: loading a library `foo' with the filename "libfoo.so" might be
   a problem, too.  For example:

	[357]% objdump -x /usr/lib/libc.so
	objdump: /usr/lib/libc.so: File format not recognized
	[358]% cat /usr/lib/libc.so
	/* GNU ld script
	  Use the shared library, but some functions are only in
	  the static library, so try that secondarily.  */
	GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
	[359]%

   I'm not sure, though, whether some other lib uses that (libc was
   the only one here on my system...).

   
So, to make it somewhat sure, that things don't break easily, I
suggest (provided it's feasible technically):

a) avoid dlopen()ing system libs (like libm.so), and instead let the
   dynamic linker do this stuff.  I noticed there is an exception of
   the dlopen rule already for `rts' and `gmp', maybe `m' should
   be added?
   
b) Iff there are any libs to dlopen(), they should be determined at
   (ghc-)build time, and we should use the SONAME.  At least on Linux
   and FreeBSD, it can be obtained by, e.g.:

	$ objdump -x {/usr,}/lib/libm.so.* | awk '/^[ ]*SONAME/ { print $2; }'

   Since we anyway have to know, which library interface version GHC
   wants to use, we can fix the SONAME at build time, I guess.

Comments?   
   
   
Cheers,
Michael
-- 
() ASCII ribbon campaign |  Chair for Computer Science  II  | GPG: F65C68CD
/\ against HTML mail     |       RWTH Aachen, Germany       | PGP: 1D0DD0B9
                    "I DO NOT HAVE DIPLOMATIC IMMUNITY"
                          -- Bart Simpson in 9F20