id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	os	architecture	failure	difficulty	testcase	blockedby	blocking	related
3072	considerations for management of shared libs	duncan	igloo	"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."	feature request	closed	low	7.6.2	Package system	6.10.1	fixed		pho@…	Linux	Unknown/Multiple	None/Unknown	Unknown