[Rd] Re: [R] LD_LIBRARY_PATH is harmfull

[Alexander Klimov]

Hi.

On Mon, 21 Feb 2005, Prof Brian Ripley wrote:
> > Consider the following situation: Solaris 8, /usr/local has gcc 2.95,
> > my home has gcc 3.4.3, my gcc is first on PATH, LD_LIBRARY_PATH is
> > unset (everything is perfect since I always use -R). In fact, programs
> > compiled with my gcc do not work if LD_LIBRARY_PATH is set to
> > something which has /usr/local/lib before home/lib, because it
> > overrides stored path (-R) and I got
> >
> >   libgcc_s.so.1 (GCC_3.3) =>       (version not found)
>
> I don't believe that happens unless `home/lib' is not in the library paths
> at all.

Notice that I do have libgcc_s in /usr/local/lib, but it is for
gcc2.95, so ldd said `(version not found)' because there is a library
but with wrong version -- I guess other libraries simply are not
considered at all.

> I've checked man ld and man ld.so.1 on Solaris 8, and neither appear
> to mention that -R is ignored if LD_LIBRARY_PATH is set.  I think
> that is a (well-buried) Solaris-specific gotcha.

The standard meaning of LD_LIBRARY_PATH is to be considered *before*
any other path.

>
> > I found setting of LD_LIBRARY_PATH in bin/R (how /usr/local/lib get
> > into it at all and especially before PREFIX/lib??? -- there was no
> > LD_LIBRARY_PATH during configure!) and fixed it (although I spent
> > quite a while editing lib/R/bin/R and wondering an abscence of
> > any effect :-)
>
> Please take a look at e.g. config.site, which explains this under LDFLAGS,
> (as does the R-admin manual which INSTALL asks you to read).

Note that I do not need any *additional* flags because
-L<home>/lib and -R<home>/lib are already in my specs file.

> > After all the troubles I manage to load an extension, but, frankly, I
> > think there were too many problems. It would be very nice if R-project
> > reject the idea of using LD_LIBRARY_PATH because its setting is
> > considered harmfull and leads to too many problems:
> > http://www.linuxmafia.com/faq/Admin/ld-lib-path.html
>
> [Which is Solaris specific, despite the site name.]

AFAIK LD_LIBRARY_PATH has the same semantic on Linux and every other
recent *nix: it overrides system-wide defaults (e.g., crle on solaris
and ldconfig on linux) as well as embeded paths; -R or -rpath are also
common among *nixes.

> Unfortunately, the alternatives lead to even more problems, and this is
> the first report we have had for years of a problem

Note that I do not have a problem with R installation, but I was
troubled to load an extension (gmp in my case).

> (which can be solved on reading the documentation)

Could you, please, enlight me what page of R-admin.pdf I missed?

> As the R-admin manual points out, we regularly test on Solaris 8 and
> give an example there of setting LDFLAGS under the Solaris section.

B.7.3 (p.22) says nothing about my case (32-bit solaris and gcc >3.3)

> Use of -R is harmful for sure!  It stops R being relocatable (so it
> either could not be tested before being installed or it would not
> run after installation),

Testing before installtion is exactly the purpose of LD_LIBRARY_PATH:
you compile with -R for final installation and use
LD_LIBRARY_PATH=<build-dir>/lib during testing. Alternatively you can
use $ORIGIN so that libraries are searched in the places relative to
executable itself.

> and it is not at all portable.

And could you name at least a single modern platform which supports
shared libraries and does not support an equivalent of -R for linking?

BTW, LD_LIBRARY_PATH also has different names on different *nix
(e.g., SHLIB_PATH on HP-UX, although AFAIK HP-UX also supports
LD_LIBRARY_PATH)

> Maybe one day when we have libtool tamed we will be able to use the
> multiple equivalents of -R or LD_RUN_PATH in a portable-enough way.
Nice to know that such plans exist :-)

-- 
Regards,
ASK