[GHC] #3072: considerations for management of shared libs
GHC
trac at galois.com
Wed Mar 4 13:12:35 EST 2009
#3072: considerations for management of shared libs
---------------------+------------------------------------------------------
Reporter: duncan | Owner:
Type: proposal | Status: new
Priority: normal | Component: None
Version: 6.10.1 | Severity: normal
Keywords: | Testcase:
Os: Linux | Architecture: Unknown/Multiple
---------------------+------------------------------------------------------
Some thought needs to be put into how to manage shared libs on the various
platforms we support. Sadly the solution is likely to be different on
Windows vs OSX vs ELF-format platforms. For ELF platforms our current idea
is to put all shared libs in `/usr{/local}/lib` with names like
`libHSfoo-x.y.z-ghc-a.b.c.so`. Having them all in the system dir like that
has it's downsides and it does not work for per-user installs. If we want
to have multiple instances of the same version of a lib then it's even
more problematic.
All ELF linkers support the RPATH/RUNPATH mechanism for executables and
shared libs to locate each other without them having to be on the standard
linker path. This basically involves embedding the path in them at link
time. It must be acknowledged that some linux distributions eschew the use
of rpath for various reasons. We must take that into consideration. Also
we must consider relocatable/redistributable binaries...
The GNU and Solaris linkers support an extension which allows the above
mechanism to work, even for relocatable binaries (so long as the libs are
kept relative to the executable). Basically one can set an rpath that uses
`$ORIGIN` and at runtime the `$ORIGIN` is substituted for the file system
location of the executable or shared lib in question.
Note that on Linux at least the `$ORIGIN` is always passed by the kernel
so that the dynamic linker can resolve it. See the attached program which
demonstrates this.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3072>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list