considerations for management of shared libs
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.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |