Skip to content

Rmpi on NetBSD with OpenMPI

2 messages · Kevin.Buckley at ecs.vuw.ac.nz

Kevin.Buckley at ecs.vuw.ac.nz
# 
It would appear there is a fix for the issue I was seeing.

After some discussion around the underlying cause of the
problem on the OpenMPI devel list, Jeff Squyres wrote:

            

      
      
      
    

        
Tying in with the suggestions Jeff makes above, there would seem to
be a work-around fix for this, in the case of the Rmpi package
on NetBSD anyway.

Furthermore, the fix does not require any alterations to OpenMPI.

Apparently, there has been a similar issue, symbol visibility
when chaining shared library loading, within PAM on NetBSD.

Mark Davies has now determined a way to force the Rmpi package
to load libmpi.so, ahead of loading the Rmpi shared library itself,
so that what appear to be the missing symbols are then available,
for any future loads of the OpenMPI component libraries.


On the version of Rmpi that I have been using, 0.5-8, the "fix"
can be effected by the following, one, line, patch

--- Rmpi/R/zzz.R        2009-02-04 05:27:08.000000000 +1300
+++ Rmpi.local/R/zzz.R  2010-05-17 14:25:27.000000000 +1200
@@ -7,6 +7,7 @@
     #    cat(vertxt)

     # Check if lam-mpi is running
+    dyn.load("/usr/pkg/lib/libmpi.so", local=FALSE)
     library.dynam("Rmpi", pkg, lib)
     if (!TRUE)
        stop("Fail to load Rmpi dynamic library.")


Note that this currently hard codes the path to the libmpi.so,
which for our system is in the standard NetBSD PkgSrc location,
though there are probably "nicer" ways to achieve the same end,
and greater flexibility, using R internals.

Having said that, this "fix" does not seem to be needed on
plaforms that have a global scope for shared library symbols,
so maybe attempts to make it generic may be pointless.

Kevin

  
    

      
      
    

  


  


    

    

      
      

        


  

        

      Kevin.Buckley at ecs.vuw.ac.nz
    

    

      
      #
    

  


  

      
I have moved this off the OpenMPI devel list as this is more
of an "interaction with OpenMPI" than an issue for the OpenMPI
development community and moved it to the R HPC SIG list as
the discussion pertains to how the Rmpi package interacts with
OpenMPI.

Aleksej (the NetBSD maintainer of OpenMPI) in response to this

            

      
      
      
    

        
writes as follows,

            

      
      
      
    

        
We, Mark in determining a fix and myself in posting it, were not
suggesting that the patch was "right", merely demonstrating that
it "worked".

As mentioned in the original R HPC SIG posting, the patch is wrong
from an Rmpi persepective too: there's not enough R there!

Furthermore, and here is where my (growing) NetBSD knowledge fails me,
it would seem likely that the package is not going to be under PkgSrc
control.

R the package, used to install Rmpi, has been patched to operate within
PkgSrc, but once you have it up and ruuning, many/most R users/deployers
would expect to just be able to run

R CMD INSTALL package

for any R add-on package.

Is there then a "standard" way to tailor R add-on packages, such as
Rmpi, to make them NetBSD aware ?

Similarly, is there a "standard" way for R packages to test for, and/or
find, a library needed in a situation like this, which would surely be
the place at which a NetBSD-aware patch should be made.

It would seem that the Rmpi package would not lose anything by testing
for, and loading if not loaded, the library on ANY platform, however
if it did so, it would then allow for a cleaner implemetation of any
platform-specific patches.