Libdl.dlopen throwing a "no error" error

[dmbates]

The description of the situation is in JuliaInterop/RCall.jl#55

On a Debian/Ubuntu system with the r-base package installed, the libR.so file is /usr/lib/R/lib/libR.so. Under Julia 0.3.8 I can dlopen that file successfully. In a recent development version a call to Libdl.dlopen fails with error "no error".

[ihnorton]

Works for me on Ubuntu 14.04 with

r-base                               3.0.2-1ubuntu1

[yuyichao]

This is also the error thrown when it cannot find the file

I've got the following error when running the test on a fresh checkout. The error is obviously file not exist but the error is confusing....

     * ccall               exception on 1: ERROR: LoadError: error compiling anonymous: could not load module ./libccalltest: no error
 in runtests at /home/yuyichao/projects/julia/master/test/testdefs.jl:198
 in anonymous at ./multi.jl:628
 in run_work_thunk at ./multi.jl:589
 in remotecall_fetch at ./multi.jl:662
 in remotecall_fetch at ./multi.jl:677
 in anonymous at ./task.jl:1392
while loading /home/yuyichao/projects/julia/master/test/ccall.jl, in expression starting on line 5
ERROR: LoadError: LoadError: error compiling anonymous: could not load module ./libccalltest: no error
 in runtests at /home/yuyichao/projects/julia/master/test/testdefs.jl:198
 in anonymous at ./multi.jl:628
 in run_work_thunk at ./multi.jl:589
 in remotecall_fetch at ./multi.jl:662
 in remotecall_fetch at ./multi.jl:677
 in anonymous at ./task.jl:1392
while loading /home/yuyichao/projects/julia/master/test/ccall.jl, in expression starting on line 5
while loading /home/yuyichao/projects/julia/master/test/runtests.jl, in expression starting on line 5

[simonbyrne]

Possibly related: #11441?

[dmbates]

Ah, so it appears that "no error" from dlopen is not informative.

I am beginning to suspect that there may be something about the way that that libR.so is being opened that is the problem. I haven't read up on the flags that are passed to the C function but will do so. ldd of the library shows

$ ldd /usr/lib/R/lib/libR.so
    linux-vdso.so.1 =>  (0x00007ffc176d2000)
    libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f845c105000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f845bdfd000)
    libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f845bbb6000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f845b949000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f845b727000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f845b516000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f845b2fb000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f845b0f3000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f845aeee000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f845acd7000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f845aab9000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f845a6ee000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f845c94d000)
    libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f8458864000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f845863b000)
    libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f8458311000)
    libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f84580d3000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8457ebc000)

Could there be cross-talk between the versions of libraries, especially BLAS and LAPACK, used by julia and used by R?

[yuyichao]

@dmbates I see in the original issue for RCall.jl that julia is able to find the library. But have you try to do dlopen in another way? (e.g. in C or python, or in julia via PyCall.jl). There's also LD_DEBUG environment variable if you suspect the dynamic linker is confused.

[simonbyrne]

You could also try merging the patch from #7940, and see if that gives more information?

[jakebolewski]

Closing as fixed now that #11488 is merged. @dmbates please reopen if this is still an issue.