JuliaCall fails with segmentation fault (core dumped)

[jalcam]

I have Julia installed with Juliaup (1.10 and 1.11). When I try to setup juliacall in R with 1.10 I get a segfault:

> library(JuliaCall)
> julia_setup(JULIA_HOME = "/home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin")
Julia version 1.10.6 at location /home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin will be used.
Loading setup script for JuliaCall...
Segmentation fault (core dumped)

when I try with Julia 1.11 the error is:

> library(JuliaCall)
> julia_setup(JULIA_HOME = "/home/juanjose/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/bin")
Julia version 1.11.1 at location /home/juanjose/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/bin will be used.
Error in juliacall_initialize(.julia$dll_file, .julia$bin_dir, img_abs_path) : 
  jl_stdout_obj - /home/juanjose/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/bin/../lib/libjulia.so.1.11: undefined symbol: jl_stdout_obj

In Julia I've tried:

julia> using RCall

julia> RCall.Rhome
"/usr/lib/R"

julia> RCall.libR
"/usr/lib/R/lib/libR.so"

julia> RCall.validate_libR(RCall.libR)
true

julia> ENV["R_HOME"] = "/usr/lib/R"
"/usr/lib/R"

julia> Pkg.build("RCall")
    Building Conda → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/b19db3927f0db4151cb86d073689f2428e524576/build.log`
    Building RCall → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/db17ec90d9f904b79e7877a764fdf95ff5c5f315/build.log`

But the segfault persists when trying JuliaCall

[ViralBShah]

Do you have something in your LD_LIBRARY_PATH or DYLD_LIBRARY_PATH or LD_PRELOAD?

[jalcam]

Do you have something in your LD_LIBRARY_PATH or DYLD_LIBRARY_PATH or LD_PRELOAD?

I have this:

> echo $LD_LIBRARY_PATH
/opt/openfoam12/thirdparty/platforms/linux64Gcc/gperftools-svn/lib:/usr/lib/x86_64-linux-gnu:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib/paraview-5.11:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib/openmpi-system:/opt/openfoam12/thirdparty/platforms/linux64GccDPInt32/lib/openmpi-system:/usr/lib/x86_64-linux-gnu/openmpi/lib:/home/jalcam/OpenFOAM/jalcam-12/platforms/linux64GccDPInt32Opt/lib:/opt/site/12/platforms/linux64GccDPInt32Opt/lib:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib:/opt/openfoam12/thirdparty/platforms/linux64GccDPInt32/lib:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib/dummy

> echo $DYLD_LIBRARY_PATH

> echo $LD_PRELOAD 

I use OpenFoam in the same computer.

[ViralBShah]

Can you unset that variable and see if it still crashes?

[jalcam]

Can you unset that variable and see if it still crashes?

I have unset the variable now:

> echo $LD_LIBRARY_PATH

But I'm getting the same error:

> library(JuliaCall)
> julia_setup(JULIA_HOME = "/home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin")
Julia version 1.10.6 at location /home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin will be used.
Loading setup script for JuliaCall...
Segmentation fault (core dumped)

[marc-milgrom-ncl]

I have downloaded Chris's latest patch branch, and devtools:check seg faults on 1.11. When I override it to build with JULIA_HOME set to the latest 1.9 release, it builds, but then julia_setup causes R to seg fault.
I'm running R 4.4.2 ETA: on Ubuntu 24.04.1 LTS. (Under WSL2 if that matters?)

[marc-milgrom-ncl]

I think I'm making progress here. julia_setup is failing, and I see this:

julia> Libdl.dlopen("/usr/local/lib/R/library/methods/libs/methods.so")
ERROR: could not load library "/usr/local/lib/R/library/methods/libs/methods.so"
libR.so: cannot open shared object file: No such file or directory
Stacktrace:
 [1] dlopen(s::String, flags::UInt32; throw_error::Bool)
   @ Base.Libc.Libdl ./libdl.jl:117
 [2] dlopen
   @ ./libdl.jl:116 [inlined]
 [3] dlopen(s::String)
   @ Base.Libc.Libdl ./libdl.jl:116
 [4] top-level scope
   @ REPL[2]:1

The methods package is installed, but I had a similar error with libRblas.so until I rebuilt R with the with-blas option. It seems like JuliaCall is expecting all the R libraries to be statically linked into libR.so or something? It's not possible to build R that way to my knowledge.

[ViralBShah]

How was the R you are using built and installed? This may be an issue with some LD_LIBRARY_PATH type setting.

I always wanted R in Yggdrasil, but IIRC, it does not support cross compilation. But maybe we can just package the upstream binaries like we do for MKL. And at least that way, we can have something that works reliably.

[marc-milgrom-ncl]

I don't have any LD_LIBRARY_PATH set, but I tried setting ENV["LD_LIBRARY_PATH"]="/usr/local/lib:/usr/local/lib/R/library" in Julia before running setup.jl to no avail.
I built R from the current 4.4.2 release source with:

sudo ./configure --enable-R-shlib --enable-memory-profiling  --with-blas --prefix=/usr/local

and then sudo make and sudo make install.

To be clear I only built it from source to enable debugging of the segmentation fault I was having with the packaged R binaries, which are stripped. This didn't help as R -d gdb isn't catching the SEGV, I think because it's actually in Julia, not R, but that's a guess.

[ViralBShah]

Is methods.so coming from JuliaCall or from R? The issue with methods.so seems to do with resolving all the dependencies for the shared library.

[marc-milgrom-ncl]

The methods.so library comes from methods, one of the expected R packages called by RCall from Julia. It happens to be one of the recommended packages included in the standard R build, i.e. unless -without-recommended-packages is specified to configure.

[marc-milgrom-ncl]

I was about to test if building R without the recommended packages and then installing them after build and install would change the behavior, but it's now 17:30 here so I'll pick this up tomorrow.

[ViralBShah]

Is there an issue with 1.10 too?

[marc-milgrom-ncl]

It also SEGV'd the last time I tried it, but that might have been with the packaged R binaries so not necessarily the same issue.

[simonbeyer1]

I had the exact same problem yesterday. Downgrading to Ubuntu 22.04.5 LTS (Jammy Jellyfish) solved the issue for me.

[marc-milgrom-ncl]

Thanks. I'll spin up a 22 VM and see if that works.