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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
