UD> Martin Buchholz <martin(a)xemacs.org&gt; writes: UD> If Sun does it this way, they are wrong. The standards explicitly say UD> it's the way we've implemented it. You cannot override a RPATH (or UD> nowadays RUNPATH) with LD_LIBRARY_PATH. Read the spcification, it's UD> freely available from SCO's web site. You know, I really try to check the standards whenever I have a question like this. I had previously made sure this stuff wasn't part of Unix98. I couldn't find any `specification' referenced on www.sco.com. I did find some man pages, and yes, they are consistent with glibc's handling of LD_LIBRARY_PATH. At the very least, please document the current behavior, and provide a reference to the `specification' on the web, and make it clear that the current behavior is _deliberately_ different from the Solaris behavior - else you're likely to get more bug reports on this. It would be nice if someone made it clear what an app's configure script is supposed to do. I wonder if libtool currently tries to provide a complete solution. Certainly on Solaris the configure script _must_ provide an RPATH. But whether to do so on Linux? My latest idea on this for XEmacs is for the XEmacs configure script to look in /etc/ld.so.conf, and then add those to the linker commands automatically, but not to use --rpath, except possibly for directories used at link time containing shared libraries, but not in /etc/ld.so.conf. Martin

UD> Martin Buchholz <martin(a)xemacs.org&gt; writes: UD> If Sun does it this way, they are wrong. The standards UD> explicitly say it's the way we've implemented it. You cannot UD> override a RPATH (or nowadays RUNPATH) with LD_LIBRARY_PATH. UD> Read the spcification, it's freely available from SCO's web site. GN> Uh, Solaris conforms to the ABI referred to above. Could you GN> repeat why you think otherwise (sorry for my lack of attention GN> earlier). According to the Linker and Libraries Guide from Sun: html: http://docs.sun.com:80/ab2/coll.45.10/LLM/＠Ab2PageView/4733?DwebQuery=Lin... PDF: ftp://192.18.99.138/805-3050/805-3050.pdf Page 48 on a printed copy: "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 start-up) can be set to a colon-separated list of directories, and these directories will be searched by the runtime linker before any runpath specification or default directory. 64-bit executables can have an LD_LIBRARY_PATH_64 variable, which overrides any active LD_LIBRARY_PATH setting." Also under Solaris(sparc) where prog has been linked with an RPATH: $ LD_LIBRARY_PATH=/no/such/directory ldd -s prog The output will show that LD_LIBRARY_PATH is searched before RPATH, so it is Solaris that does not conform to the ABI. -Jimi X BTW: I'm not sure if the SPARC ABI supplement can override the Generic ABI on this function (or even if it does), but if the same happens on Solaris x86 (Georg?) and the x86 supplement does not seem to mention (I couldn't find it) then Solaris clearly does not conform.

GN> What you're looking for is an ABI spec which unfortunately is out of GN> print. However, GN> http://www.sco.com/developer/gabi/ch5.dynamic.html#shobj_dependencies GN> is what I think Ulrich refers to (5-20 if you happen to have a print GN> copy). MB> At the very least, please document the current behavior, and MB> provide a reference to the `specification' on the web, and make MB> it clear that the current behavior is _deliberately_ different MB> from the Solaris behavior - else you're likely to get more bug MB> reports on this. GN> Uh, Solaris conforms to the ABI referred to above. Could you repeat GN> why you think otherwise (sorry for my lack of attention earlier). glibc, and the page at www.sco.com you quoted, have executable RPATH take precedence over LD_LIBRARY_PATH. Quote from the web page: ``All LD_LIBRARY_PATH directories are searched after those from DT_RPATH'' My copy of Solaris 2.6 has LD_LIBRARY_PATH take precedence over RPATH (I just tested it again to make sure). Here are interesting extracts from the libtool manual (recommended reading): - Variable: shlibpath_overrides_runpath Indicates whether it is possible to override the hard-coded library search path of a program with an environment variable. If this is set to no, libtool may have to create two copies of a program in the build tree, one to be installed and one to be run in the build tree only. When each of these copies is created depends on the value of `fast_install'. The default value is `unknown', which is equivalent to `no'. - Variable: fast_install Determines whether libtool will privilege the installer or the developer. The assumption is that installers will seldom run programs in the build tree, and the developer will seldom install. This is only meaningful on platforms in which SHLIBPATH_OVERRIDES_RUNPATH is not `yes', so FAST_INSTALL will be set to `needless' in this case. If FAST_INSTALL set to `yes', libtool will create programs that search for installed libraries, and, if a program is run in the build tree, a new copy will be linked on-demand to use the yet-to-be-installed libraries. If set to `no', libtool will create programs that use the yet-to-be-installed libraries, and will link a new copy of the program at install time. The default value is `yes' or `needless', depending on platform and configuration flags, and it can be turned from `yes' to `no' with the configure flag `--disable-fast-install'.