Launch Failure

New to Julia
1

I am using an up to date arch linux distro. I’ve downloaded julia-1.6.7 from the official website and set the path. When I run julia in a console I get the following error:

┌ Warning: CHOLMOD version incompatibility
│
│ Julia was compiled with CHOLMOD version 3.0.13. It is
│ currently linked with version 4.0.4.
│ This might cause Julia to terminate when working with
│ sparse matrix factorizations, e.g. solving systems of
│ equations with \.
│
│ It is recommended that you use Julia with the same major
│ version of CHOLMOD as the one used during the build, or
│ download the generic binaries from www.julialang.org,
│ which ship with the correct versions of all dependencies.
└ @ SuiteSparse.CHOLMOD /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/SuiteSparse/src/cholmod.jl:115
┌ Error: Error during initialization of module CHOLMOD
│   exception =
│    could not load symbol "SuiteSparse_config":
│    /lib/libsuitesparseconfig.so.7: undefined symbol: SuiteSparse_config
│    Stacktrace:
│     [1] __init__()
│       @ SuiteSparse.CHOLMOD /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/SuiteSparse/src/cholmod.jl:179
└ @ SuiteSparse.CHOLMOD /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/SuiteSparse/src/cholmod.jl:187
fatal: error thrown and no exception handler available.
InitError(mod=:LibCURL_jll, error=ErrorException("could not load library "libcurl.so"
/lib/libcurl.so: undefined symbol: libssh2_session_set_read_timeout"))
jl_errorf at /buildworker/worker/package_linux64/build/src/rtutils.c:77
jl_load_dynamic_library at /buildworker/worker/package_linux64/build/src/dlload.c:281
#dlopen#3 at ./libdl.jl:114
dlopen at ./libdl.jl:114 [inlined]
dlopen at ./libdl.jl:114
jfptr_dlopen_38581.clone_1 at /home/hany/julia-1.6.7/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2237 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2419
__init__ at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/LibCURL_jll/src/LibCURL_jll.jl:30
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2237 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2419
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1703 [inlined]
jl_module_run_initializer at /buildworker/worker/package_linux64/build/src/toplevel.c:72
_julia_init at /buildworker/worker/package_linux64/build/src/init.c:794
repl_entrypoint at /buildworker/worker/package_linux64/build/src/jlapi.c:696
main at julia (unknown line)
unknown function (ip: 0x7ff052a27ccf)
__libc_start_main at /lib/libc.so.6 (unknown line)
unknown function (ip: 0x4007d8)

Any ideas? Weirdly enough, if I run “sudo julia”, the REPL launches.

2

Do you have any particular setting of LD_PRELOAD or LD_LIBRARY_PATH? How/where did you install Julia to? Does it work correctly with a newer Julia version (the LTS is really only expected to be used if you can’t upgrade for other reasons - newer minor versions are very stable)?

3

I did have LD_LIBRARY_PATH set to /usr/lib in my zshrc for a different reason. Julia is
in my home directory.

Un-setting the library path and using the latest julia 1.9.3 appears to solve the CHOLMOD warning and the missing library issue.

4

Would be interesting to know which one did the trick. I think Julia 1.9 ships with libcholmod.4, hence wouldn’t complain about loading a system installed copy of the library. (edit: no, 1.10 does)

On the other hand, the Julia binary should have an RPATH set, so the loader wouldn’t bother about looking in LD_LIBRARY_PATH in the first place…? Unless the lib/ folder in the julia directory was missing or incomplete.

I’m possibly getting this wrong.

5

I’m not sure 1.6.7 had the RPATH set correctly. There was some work on that since then, if I recall correctly.

6

Would be interesting to know which one did the trick

I am not very sure. If I keep my custom LD_LIBRARY_PATH and use 1.9.3, I still get the CHOLMOD warning but instead of the libcurl exception I get a segfault.

For reference these are the commands I had zshrc

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
7

Has for me.

skleinbo $ ~/.julia/juliaup/julia-1.6.7+0.x64.linux.gnu/bin  readelf -d ./julia

Dynamic section at offset 0xdc8 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libjulia.so.1]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib:$ORIGIN/../lib/julia]

Can you launch LD_DEBUG=libs julia 2> libsdebug and have a look for libcholmod.so in libsdebug? That should tell you where the loader is searching.

8

It appears to be searching in the LD_PATH_LIBRARY first then in RPATH? That happens in 1.6.7 and 1.9.3

    104456:	find library=libcholmod [0]; searching
    104456:	 search path=glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2::/lib		(LD_LIBRARY_PATH)
    104456:	  trying file=glibc-hwcaps/x86-64-v3/libcholmod
    104456:	  trying file=glibc-hwcaps/x86-64-v2/libcholmod
    104456:	  trying file=libcholmod
    104456:	  trying file=/lib/libcholmod
    104456:	 search path=/usr/lib		(system search path)
    104456:	  trying file=/usr/lib/libcholmod
    104456:	 search path=/home/hany/julia-1.6.7/bin/../lib/julia		(RPATH from file julia)
    104456:	  trying file=/home/hany/julia-1.6.7/bin/../lib/julia/libcholmod
    104456:	 search path=/home/hany/julia-1.6.7/bin/../lib/julia/..		(RUNPATH from file /home/hany/julia-1.6.7/bin/../lib/julia/libjulia-internal.so.1)
    104456:	  trying file=/home/hany/julia-1.6.7/bin/../lib/julia/../libcholmod
    104456:	 search cache=/etc/ld.so.cache
    104456:	 search path=/usr/lib		(system search path)
    104456:	  trying file=/usr/lib/libcholmod
    104456:	
    104456:	find library=libcholmod.so [0]; searching
    104456:	 search path=glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2::/lib		(LD_LIBRARY_PATH)
    104456:	  trying file=glibc-hwcaps/x86-64-v3/libcholmod.so
    104456:	  trying file=glibc-hwcaps/x86-64-v2/libcholmod.so
    104456:	  trying file=libcholmod.so
    104456:	  trying file=/lib/libcholmod.so
9

btw un-setting the LD_LIBRARY_PATH solves the problem for both 1.6.7 and 1.9.3. The REPL launches in both cases with no warnings. I am not sure I made that point clear before.

10

Okay, so the loader looks in LD_LIBRARY_PATH first find libcholmod because you have /lib in that path. Is that really necessary by the way?

And now I think I figured out why. Apparently, the binary not only defines RPATH (which is deprecated anyway), but RUNPATH too.
From the manpage of ld.so:

If a shared object dependency does not contain a slash, then it is searched for in the following order:

(1)
Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated.
(2)
Using the environment variable LD_LIBRARY_PATH, unless the executable is being run in secure-execution mode (see below), in which case this variable is ignored.
(3)
Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.

I.e. if RUNPATH is specified, LD_LIBRARY_PATH takes precedent.

Thus the question from above: Do you need /lib and /usr/lib in there?

11

No, I don’t really need it. I think this was a legacy workaround for compiling mex files in MATLAB, which I don’t need anymore. Thanks for helping nailing it down.

1 Like