R Hayes wrote:
I will reiterate what I understand the goals to be:
1) When creating an executable, specify where the dynamic loader should
look for shared libraries at runtime. The intent is to expand the
shared library search space beyond the default search path and remove
the need to set environment variables.
2) When running an executable, override the default. Primarily a
requirement for building GHC.
I would add:
3) Building binary distributions of ghc-compiled programs. Those can't
use -rpath for obvious reasons.
4) ghc-inplace should be able to produce binaries which use libraries
from the uninstalled tree. Hacking on ghc would become rather
annoying otherwise.
For Mac: The -rpath switch is not available on Mac OS X because it is
superfluous. The default behavior of embedding a location for each
individual shared library is at least as good. Cabal (and the GHC build
process) should use their knowledge of the ultimate install location to
set the install name when shared libraries are built. In-place
compilation can override this with DYLD_LIBRARY_PATH
The problem is that this scheme doesn't really account for 3) and 4).
For Linux: On linux, we should be sure to use the --enable-new-dtags
switch if we use -rpath. Otherwise we risk having paths that can't be
overridden by LD_LIBRARY_PATH. I know we don't want to have an install
that *requires* root access, but we should consider adding entries to
/etc/ld.so.conf and running ldconfig to eliminate the need to hardwire
path names.
IMO, this is a very bad idea. It shouldn't be necessary and if it was it
would be the OS package manager's job to add such entries upon
installation and, crucially, to remove them upon deinstallation.
Roman
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
