2 versions of same library loaded

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

2 versions of same library loaded

Ross Boylan
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?

Can I assume the highest version number of a library will be preferred?
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."

Why is /usr/lib/openmpi being looked at in the first place?

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.

Thanks.
Ross Boylan

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2 versions of same library loaded

Simon Urbanek
Ross,

On Mar 12, 2014, at 5:34 PM, Ross Boylan <[hidden email]> 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.


> 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.


> 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).

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.


> 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.

Cheers,
Simon


> Thanks.
> Ross Boylan
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2 versions of same library loaded

Ross Boylan
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 <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2 versions of same library loaded

William Dunlap
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: [hidden email] [mailto:[hidden email]] On Behalf
> Of Ross Boylan
> Sent: Wednesday, March 12, 2014 10:01 PM
> To: Simon Urbanek
> Cc: [hidden email]
> 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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2 versions of same library loaded

Ross Boylan
On Thu, 2014-03-13 at 15:21 +0000, William Dunlap wrote:
> 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
That was very helpful.  I'm still having trouble determining exactly
which file is getting loaded, because the trace sometimes does not
include the complete path.  However, judging by calls to init I can see

1. My premise that R had no references to mpi was incorrect.  The logs
show      
24312:     file=libmpi.so.1 [0];  needed by /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so [0]
24312:     find library=libmpi.so.1 [0]; searching
24312:      search path=/usr/lib64/R/lib:/home/ross/install/lib            (LD_LIBRARY_PATH)
24312:       trying file=/usr/lib64/R/lib/libmpi.so.1
24312:       trying file=/home/ross/install/lib/libmpi.so.1

I used
   env LD_DEBUG='libs files versions' R
to try to get more clues about what was going on.

2.  There are calls to init for
calling init: /home/ross/install/lib/libmpi.so.1
calling init: /usr/lib/libmpi.so.0
in that order.

mpi.so.0 is there because
     24312:     file=libmpi.so.0 [0];  needed by /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so [0]
     24312:     find library=libmpi.so.0 [0]; searching
     24312:      search path=/usr/lib64/R/lib:/home/ross/install/lib            (LD_LIBRARY_PATH)
     24312:       trying file=/usr/lib64/R/lib/libmpi.so.0
     24312:       trying file=/home/ross/install/lib/libmpi.so.0
     24312:      search cache=/etc/ld.so.cache
     24312:       trying file=/usr/lib/libmpi.so.0

It seems very odd that the same Rmpi.so is requiring both the old and new libmpi.so (compare to the first
trace in in point 1).  There is this code in Rmpi.c:
    if (!dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
        && !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)){


So I'm still not sure what it's using, or if there is some mishmash of the 2.

It might be relevant that
     24312:     calling init: /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so
     24312:
     24312:     opening file=/home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so [0]; direct_opencount=1
     24312:
     24312:     /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so: error: symbol lookup error: undefined symbol: R_init_Rmpi (fatal)
     24312:     /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so: error: symbol lookup error: undefined symbol: R_init_Rmpi (fatal)

ldd on Rmpi.so has no mention of mpi.so.0:
$ ldd /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so
        linux-vdso.so.1 =>  (0x00007fff69135000)
        libmpi.so.1 => /home/ross/install/lib/libmpi.so.1 (0x00007f899b579000)
        libR.so => /usr/lib/libR.so (0x00007f899af8c000)
        libc.so.6 => /lib/libc.so.6 (0x00007f899ac29000)
        libibverbs.so.1 => /usr/lib/libibverbs.so.1 (0x00007f899aa1d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f899a801000)
        libopen-rte.so.7 => /home/ross/install/lib/libopen-rte.so.7 (0x00007f899a518000)
        libtorque.so.2 => /usr/lib/libtorque.so.2 (0x00007f899a208000)
        libopen-pal.so.6 => /home/ross/install/lib/libopen-pal.so.6 (0x00007f8999f34000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f8999d2f000)
        libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007f8999b27000)
        libpciaccess.so.0 => /usr/lib/libpciaccess.so.0 (0x00007f899991f000)
        librt.so.1 => /lib/librt.so.1 (0x00007f8999716000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00007f89994fe000)
        libutil.so.1 => /lib/libutil.so.1 (0x00007f89992fb000)
        libm.so.6 => /lib/libm.so.6 (0x00007f8999078000)
        libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007f8998b58000)
        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f899886c000)
        libreadline.so.6 => /lib/libreadline.so.6 (0x00007f8998627000)
        libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f899841a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f899bc6e000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f8998202000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f8997fec000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x00007f8997da6000)

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2 versions of same library loaded

Ross Boylan
On Thu, 2014-03-13 at 10:46 -0700, Ross Boylan wrote:
> 1. My premise that R had no references to mpi was incorrect.  The logs
> show      
> 24312:     file=libmpi.so.1 [0];  needed
> by /home/ross/Rlib-3.0.1/Rmpi/libs/Rmpi.so [0]
> 24312:     find library=libmpi.so.1 [0]; searching
> 24312:      search path=/usr/lib64/R/lib:/home/ross/install/lib
> (LD_LIBRARY_PATH)
> 24312:       trying file=/usr/lib64/R/lib/libmpi.so.1
> 24312:       trying file=/home/ross/install/lib/libmpi.so.1

Except there is no file /usr/lib64/R/lib/libmpi.so.1

>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 2 versions of same library loaded

Ross Boylan
In reply to this post by Ross Boylan
On Thu, 2014-03-13 at 10:46 -0700, Ross Boylan wrote:

>
> It seems very odd that the same Rmpi.so is requiring both the old and
> new libmpi.so (compare to the first
> trace in in point 1).  There is this code in Rmpi.c:
>     if (!dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
>         && !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)){
>
>
> So I'm still not sure what it's using, or if there is some mishmash of
> the 2.

There is an explanation for the explicit load in the Changelog:
2007-10-24, version 0.5-5:

dlopen has been used to load libmpi.so explicitly. This is mainly useful
for Rmpi under OpenMPI where one might see many error messages:
mca: base: component_find: unable to open osc pt2pt: file not found
(ignored) if libmpi.so is not loaded with RTLD_GLOBAL flag.
http://www.stats.uwo.ca/faculty/yu/Rmpi/changelogs.htm

There is another interesting note about openmpi:
It looks like that the option --disable-dlopen is not necessary to
install Open MPI 1.6, at least on Debian. This might be R's .onLoad
correctly loading dynamic libraries and Open MPI is not required to be
compiled with static libraries enabled.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel