OSError: lib/libRrefblas.so: undefined symbol: xerbla_

[rentrop]

Thanks for sharing your code on how to use R on AWS.

Unfortunately if i follow your code with the current Lambda-AMI i get the following error when testing it on a new AWS instance:

[ec2-user@***]$ python ./test_handler.py
Traceback (most recent call last):
  File "./test_handler.py", line 17, in <module>
    import handler
  File "/home/ec2-user/handler.py", line 29, in <module>
    ctypes.cdll.LoadLibrary(os.path.join('lib', file))
  File "/usr/lib64/python2.7/ctypes/__init__.py", line 438, in LoadLibrary
    return self._dlltype(name)
  File "/usr/lib64/python2.7/ctypes/__init__.py", line 360, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: lib/libRrefblas.so: undefined symbol: xerbla_

I tried googling for it but unfortunately do not understand how to fix this...
Any idea?

While running the script it throws the following error:

cp: cannot stat '/usr/lib64/libblas.so.3': No such file or directory
cp: cannot stat '/usr/lib64/liblapack.so.3': No such file or directory

I tried installing these libraries using

sudo yum -y install blas
sudo yum -y install lapack

And then ran the script again... still same error

The script installs the current R version 3.3.2 - dont know if this helps

Might that have something to do with openBlas VS blas?
https://bodhi.fedoraproject.org/updates/rkward-0.6.5-3.fc24%20rpy-2.8.3-1.fc24%20R-3.3.2-2.fc24/edit

[nmcginn]

@rentrop I don't think that's 100% the culprit, I tried following their instructions

If you wish to use that, just delete the openBLAS symlink, then rename libRrefblas.so to libRblas.so.

I still got the same error. Unfortunately the AMI referenced in the instructions is from 2015, I'm trying to figure out a solution w/ Docker but the oldest supported images on docker hub are late 2016 which leads me to believe they won't be compatible with Lambda regardless.

[nmcginn]

@rentrop Follow-up, I was able to get it working using the latest amazon linux AMI. It looks like the libRrefblas.so packaged with R is actually the one that's suspect. If you don't run your yum installs for blas & lapack, you can do something like the following for the native dependencies (notice the rm on the first line):

# start assembling binaries
rm /usr/lib64/R/lib/libRrefblas.so
cp -r /usr/lib64/R/* lambda/
cp /usr/lib64/R/lib/libR.so lambda/lib/libR.so

# all the binaries we need
cp /usr/lib64/libgomp.so.1 lambda/lib/
cp /usr/lib64/libgfortran.so.3 lambda/lib/
cp /usr/lib64/libquadmath.so.0 lambda/lib/
cp /usr/lib64/libblas.so.3 lambda/lib/
cp /usr/lib64/liblapack.so.3 lambda/lib/
cp /usr/lib64/libtre.so.5 lambda/lib/

This will cause R to reference its included libRblas.so which makes everything functional again 😄

[rentrop]

So you found a solution... Great

[jiminygreen]

Afternoon,

When running the build .sh file the rm (remove file) says 'permission denied'.

when testing the line on it own it addressed that by using the sudo command. Should i add 'sudo' to the build file or is there another way to solve this?

Thanks
Jiminy

[nmcginn]

@jiminygreen A sudo is fine or you can run sudo chown username /usr/lib64/R/lib/libRrefblas.so prior to it. By default it's probably owned by root.