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