[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Linking setup with gnustep-make 2.0.1 on Solaris
From: |
Vaisburd, Haim |
Subject: |
RE: Linking setup with gnustep-make 2.0.1 on Solaris |
Date: |
Tue, 12 Jun 2007 15:34:58 -0700 |
Fabien Groffen> We [gentoo] use some experimental -rpath (-R) support
for Linux
Fabien Groffen> (and Solaris), which seems to work fine so far, thereby
eliminating the
Fabien Groffen> dreaded LD_LIBRARY_PATH variable.
Fabien Groffen> I'm not sure why the GNUstep developers chose for this
approach.
Richard Frith-MacDonald> Use of -R is generally considered a really bad
idea
Richard Frith-MacDonald> for any software where you don't tightly
control the deployment environment,
Richard Frith-MacDonald> because it hard-codes filesystem locations into
the binary, and the libraries
Richard Frith-MacDonald> you want to use may well not be in the same
location on the target machine
Richard Frith-MacDonald> that they are in on the build machine.
I have to say I was taught the way Fabian says,
i.e. RPATH is better than reliance on LD_LIBRARY_PATH.
Here is a quote from Sun Linker and Libraries Guide
(http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl1d?a=view)
(mind you, however, that Solaris supports $ORIGIN in RPATH):
<Quote>
Another way to add to the runtime linker's search path
is to set the environment variable LD_LIBRARY_PATH.
This environment variable, which is analyzed once at process
startup, can be set to a colon-separated list of directories.
These directories are searched by the runtime linker before
any runpath specification or default directory.
These environment variables are well suited to debugging purposes,
such as forcing an application to bind to a local dependency [...]
Although useful as a temporary mechanism of influencing the runtime
linker's search path, the use of LD_LIBRARY_PATH is strongly discouraged
in production software. Any dynamic executables that can reference
this environment variable will have their search paths augmented.
This augmentation can result in an overall degradation in performance.
Also, as pointed out in Using an Environment Variable and Directories
Searched by the Runtime Linker, LD_LIBRARY_PATH affects the link-editor.
</Quote>
Richard Frith-MacDonald> So -R generally only makes sense for people who
are packaging distributions
Richard Frith-MacDonald> where the location of everything is fixed.
We use $ORIGIN in what we ship on Solaris so the package can be moved
_as a whole_, provided that the directory layout within the package
is not changed. I think this is both flexible and robust.
Nicola Pero> But if people try to move things around a little bit,
Nicola Pero> hardcoded paths can become a pain.
I just checked: LD_LIBRARY_PATH has a preference over RPATH that's
in the binary for both Solaris 10 and Linux 2.6.18/glibc 2.5.
So it seems that we can set RPATH and still have the current mechanism
working.
If the system supports $ORIGIN, I would set RPATH to the lib directory
which is relative to the supposed installation place, i.e. to
$ORIGIN/../../../System/Library/Libraries:$ORIGIN/../../../Local/Library
/Libraries
Thank you,
Tima