[Rd] 2 versions of same library loaded

Thu Mar 13 16:21:26 CET 2014

Have you tried using the environment variable LD_DEBUG to
see what the dynamic linker is doing?  E.g.,

  env LD_DEBUG=files R
or
  % setenv RHOME `R RHOME`
  % R CMD env LD_DEBUG=files $RHOME/bin/exec/R
      2322:
      2322:     file=libR.so [0];  needed by /opt/sw/R/R-3.0.2.atlas1/lib/R/bin/exec/R [0]
      2322:     file=libR.so [0];  generating link map
      2322:       dynamic: 0x00007f484e2da0b8  base: 0x00007f484de30000   size: 0x00000000005a0c60
      2322:         entry: 0x00007f484de59e60  phdr: 0x00007f484de30040  phnum:                  7
      2322:
      2322:
      2322:     file=libpthread.so.0 [0];  needed by /opt/sw/R/R-3.0.2.atlas1/lib/R/bin/exec/R [0]
      2322:     file=libpthread.so.0 [0];  generating link map
      2322:       dynamic: 0x00007f484de2ad88  base: 0x00007f484dc13000   size: 0x000000000021c438
      2322:         entry: 0x00007f484dc19c50  phdr: 0x00007f484dc13040  phnum:                  9
      2322:
      2322:
      2322:     file=libc.so.6 [0];  needed by /opt/sw/R/R-3.0.2.atlas1/lib/R/bin/exec/R [0]
      2322:     file=libc.so.6 [0];  generating link map
      2322:       dynamic: 0x00007f484dc0bb40  base: 0x00007f484d870000   size: 0x00000000003a2368
      2322:         entry: 0x00007f484d891420  phdr: 0x00007f484d870040  phnum:                 10
      ...
      > library(lme4)
      ... lots more messages about shared objects being loaded.

See 'man ld.so' for more information; run 'env LD_DEBUG=help echo foo' for the available options.

> > > Before running I set LD_LIBRARY_PATH to
> > > ~/install/lib, and then stuffed the same path at the start of
> > > LD_LIBRARY_PATH using Sys.setenv in my profile
It has been a long time since I worried about these things, but I thought that changing
LD_LIBRARY_PATH after a process starts has no effect on the dynamic linking done for
the current process - ld.so only looks at LD_LIBRARY_PATH when ls.so starts.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

> -----Original Message-----
> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On Behalf
> Of Ross Boylan
> Sent: Wednesday, March 12, 2014 10:01 PM
> To: Simon Urbanek
> Cc: r-devel at r-project.org
> Subject: Re: [Rd] 2 versions of same library loaded
> 
> Comments/questions interspersed below.
> On Wed, 2014-03-12 at 22:50 -0400, Simon Urbanek wrote:
> > Ross,
> >
> > On Mar 12, 2014, at 5:34 PM, Ross Boylan <ross at biostat.ucsf.edu> wrote:
> >
> > > Can anyone help me understand how I got 2 versions of the same library
> > > loaded, how to prevent it, and what the consequences are?  Running under
> > > Debian GNU/Linux squeeze.
> > >
> > > lsof and /proc/xxx/map both show 2 copies of several libraries loaded:
> > > /home/ross/install/lib/libmpi.so.1.3.0
> > > /home/ross/install/lib/libopen-pal.so.6.1.0
> > > /home/ross/install/lib/libopen-rte.so.7.0.0
> > > /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so
> > > /usr/lib/openmpi/lib/libmpi.so.0.0.2
> > > /usr/lib/openmpi/lib/libopen-pal.so.0.0.0
> > > /usr/lib/openmpi/lib/libopen-rte.so.0.0.0
> > > /usr/lib/R/lib/libR.so
> > >
> > >
> > > The system has the old version of MPI installed under /usr/lib.  I built
> > > a personal, newer copy in my directory, and then rebuilt Rmpi (an R
> > > package) against it.  ldd on the personal Rmpi.so and libmpi.so shows
> > > all references to mpi libraries on personal paths.
> > >
> > > R was installed from a debian package, and presumably compiled without
> > > having MPI around.  Before running I set LD_LIBRARY_PATH to
> > > ~/install/lib, and then stuffed the same path at the start of
> > > LD_LIBRARY_PATH using Sys.setenv in my profile because R seems to
> > > prepend some libraries to that path when it starts (I'm curious about
> > > that too).  I also prepended ~/install/bin to my path, though I'm not
> > > sure that's relevant.
> > >
> > > Does R use ld.so or some other mechanism for loading libraries?
> > >
> >
> > R uses dlopen to load package libraries - it is essentially identical to using ld.so for
> dependencies.
> >
> >
> > > Can I assume the highest version number of a library will be preferred?
> >
> > No.
> >
> Bummer.  The fact that Rmpi is not crashing suggests to me it's using
> the right version of the mpi libraries (it does produce lots of errors
> if I run it without setting LD_LIBRARY_PATH so only the system mpi libs
> are in play), but it would be nice to be certain.  Or the 2 versions
> could be combined in a big mess.
> >
> > > http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#index-Dynamic-loading
> says "If a shared object/DLL is loaded more than once the most recent version is used."
> I'm not sure if "most recent" means the one loaded most recently by the program (I don't
> know which that is) or "highest version number."
> > >
> >
> > The former - whichever you load last wins. Note, however, that this refers to explicitly
> loaded objects since they are loaded into a flat namespace so a load will overwrite all
> symbols that get loaded.
> It might be good to clarify that in the manual.
> 
> If I understand the term, the mpi libraries are loaded implicitly; that
> is, Rmpi.so is loaded explicitly, and then it pulls in dependencies.
> What are the rules in that case?
> 
> >
> >
> > > Why is /usr/lib/openmpi being looked at in the first place?
> > >
> >
> > You'll have to consult your system. The search path (assuming rpath is not involved) is
> governed by LD_LIBRARY_PATH and /etc/ld.so.conf*. Note that LD_LIBRARY_PATH is
> consulted at the time of the resolution (when the library is looked up), so you may be
> changing it too late. Also note that you have to expand ~ in the path (it's not a valid path,
> it's a shell expansion feature).
> >
> I just used the ~ as a shortcut; the shell expanded it and the full path
> ended up in the variable.
> 
> I assume the loader checks LD_LIBRARY_PATH first; once it finds the mpi
> libraries there I don't know why it keeps looking.
> 
> I'm not sure I follow the part about too late, but is it this?: all the
> R's launched under MPI have the MPI library loaded automatically.   If
> that happens before my profile is read, reseting LD_LIBRARY_PATH will be
> irrelevant.  I don't know whether the profile or Rmpi load happens
> first.
> 
> The reseting is just a reordering, and since the  other elements in
> LD_LIBRARY_PATH don't have any mpi libraries I don't think the order
> matters.
> 
> 
> > R's massaging of the LD_LIBRARY_PATH is typically done in $R_HOME/etc/ldpaths so
> you may want to check it and/or adjust it as needed. Normally (in stock R), it only
> prepends its own libraries and Java so it should not be causing any issues, but you may
> want to check in case Debian scripts add anything else.
> >
> The extra paths are limited as you describe, and so are probably no
> threat for loading the wrong MPI library
> (/usr/lib64/R/lib:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server).
> >
> > > How can I stop the madness?  Some folks on the openmpi list have
> > > indicated I need to rebuild R, telling it where my MPI is, but that
> > > seems an awfully big hammer for the problem.
> > >
> >
> > I would check LD_LIBRARY_PATH and also check at which point are those old libraries
> loaded to find where they are referenced.
> How do I tell the point at which the old libraries are loaded?  I assume
> it happens implicitly when Rmpi is loaded, but I don't know which of the
> 2 versions of the libraries is loaded first, and I don't know how to
> tell.
> 
> Thanks for your help.
> Ross Boylan
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel