[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