[Rd] Re: [R] LD_LIBRARY_PATH is harmfull

[Alexander Klimov]

On Mon, 21 Feb 2005, Prof Brian Ripley wrote:
> >>>   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.
>
> Something is very strange: notice you say you have 3.4.3 and it is looking
> for GCC_3.3!

This is as it is supposed to be. Try to
$ objdump -p file | grep GCC_
where file is either executable or library, e.g.,
objdump -p ~/soft/lib/libgcc_s.so | grep GCC_

In order to get better understanding of DSO consider reading
http://people.redhat.com/drepper/dsohowto.pdf

> I get
>
>          libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
>
> and no version number.

It is because in your case .so has correct version

> >> 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.
>
> Yes.  That is not what you say happens for you, though, rather you are
> sayin *instead of*.

Let's try again: my problem is not that I do not have libgcc_s in the
search path, but that due to R's LD_LIBRARY_PATH the first libgcc_s in
the path has incorrect version.

> > Note that I do not need any *additional* flags because
> > -L<home>/lib and -R<home>/lib are already in my specs file.
>
> You need something to find R's shared libraries, e.g. libRlapack.

This could be easily done with -R, and due to $ORIGIN this could be
simpler than with LD_LIBRARY_PATH

> > 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.
>
> The issue is if they are ignored, not if they are overridden.

Who said that they are *always* ignored? They definitely ignored if
due to LD_LIBRARY_PATH some incorrect library was found before.

> > Could you, please, enlight me what page of R-admin.pdf I missed?
>
> No, as I don't have your layout.  But it _is_ there:
>
> If you have libraries and header files, e.g., for @acronym{GNU}
> readline, in non-system directories, use the variables @code{LDFLAGS}
> (for libraries, using @samp{-L} flags to be passed to the linker) and
> @code{CPPFLAGS} (for header files, using @samp{-I} flags to be passed to
> the C/C++ preprocessors), respectively, to specify these locations.
> These default to @file{/usr/local/lib} and @file{/usr/local/include} to
> catch the most common cases.
>
> [You clearly do so have.]

But, as I already said this is not applicable to me since I do not
need any additional flags!

> Library paths specified as @option{-L/lib/path} in @code{LDFLAGS} are
> collected together and prepended to @env{LD_LIBRARY_PATH} (or your
> system's equivalent), so there should be no need for @option{-R} or
> @option{-rpath} flags.

And since I have not specified anything for -L nothing should be added
to LD_LIBRARY_PATH. But I guess I should understand this as the
default /usr/local/lib will be added which I don't think a good idea:
if everything works for a user with his LD_LIBRARY_PATH, why add
something which is not under R_HOME.

> >> 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)
>
> It gives an example of setting LDFLAGS: you cannot expect every user's
> setup to be mentioned.

Let's try again: I do not need any -L flags.

> > And could you name at least a single modern platform which supports
> > shared libraries and does not support an equivalent of -R for linking?
>
> Windows (probably the most-used platform for R).

Yes, you are right, OTOH dll support on windows is very different
anyway.

-- 
Regards,
ASK