Re: [Rd] Re: [R] LD_LIBRARY_PATH is harmfull

From: Alexander Klimov <alserkli_at_inbox.ru>
Date: Tue 22 Feb 2005 - 00:55:38 EST

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

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Tue Feb 22 00:03:04 2005

This archive was generated by hypermail 2.1.8 : Tue 22 Feb 2005 - 01:31:45 EST