Error loading OpenSSL_jll (“version OPENSSL_3.3.0 not found”) when precompiling MLDatasets

General Usage
,
1

Environment

  • Julia version: 1.8
  • OS: Linux (64-bit)
  • OpenSSL_jll artifact path: /export/usuarios01/jmfrutos/.julia/artifacts/a696e1e3e6b8d3c2c4b67609357ebc5c35eabde1/lib/libssl.so

When I run:

using MLDatasets

I get the following cascade of precompilation failures:

ERROR: LoadError: InitError: could not load library 
"/export/usuarios01/jmfrutos/.julia/artifacts/.../libssl.so"
/usr/lib64/libcrypto.so.3: version `OPENSSL_3.3.0' not found 
(required by ...)                          
Stacktrace:
 [1] macro expansion at .../JLLWrappers/.../library_generators.jl:63
 [2] __init__() at .../OpenSSL_jll/.../x86_64-linux-gnu.jl:16
 [3] top-level scope at stdin:1
during initialization of module OpenSSL_jll
in expression starting at .../OpenSSL.jl:1

ERROR: LoadError: Failed to precompile OpenSSL [...]
ERROR: LoadError: Failed to precompile HTTP [...]
ERROR: LoadError: Failed to precompile DataDeps [...]
ERROR: Failed to precompile MLDatasets [...]

I am running into a server so I can not Update OpenSSL.

How can I solve this problem? And What is really the problem? Sometimes it works sometimes not

2

Somehow you’re loading a system library, that’s your issue. Why that’s the case, you need to tell us.

1 Like
3

I have the same issue on a local cluster.

EDIT: It was a loaded conda module that linked to the system libcrypto.so.3 in my case.

4

Try doing using OpenSSL_jll before anything else.

1 Like
5

I recently ran into this problem on a cluster running Rocky Linux 9.2, which is basically the same as RHEL 9.2. The problem in my case turned out to be the LD_LIBRARY_PATH environment variable, which was being set by a line I added long ago to my ~/.bashrc file. To fix some other problem, I’d added this line

export LD_LIBRARY_PATH=/usr/lib64/:....

This was setting the LD_LIBRARY_PATH environment variable, which the Julia process inherits from the shell. That setting forces the operating system to look in /usr/lib64 and a few other directories any time a program tries to load a .so file. Since libssl.so lists that it requires libcrypto.so.3, the operating system would find /usr/lib64/libcrypto.so.3 which is from a system-wide installation of OpenSSL, and try to load that. But the system file is from an older version of OpenSSL than the Julia package can use.

To fix the problem, I commented that line out of my ~/.bashrc by putting a # at the beginning of the line. I logged out & logged back in again. Now nothing is setting that environment variable, and Julia can load MLJ without that error. When Julia loads libssl.so from the file in ~/.julia/artifacts/..., the operating has to also load libcrypto.so.3 from somewhere, because libssl.so lists that it requires it. Since I’m no longer setting LD_LIBRARY_PATH, the operating system loads libcrypto.so.3 from the same directory in ~/.julia/artifacts/... where it found libssl.so, and that’s the correct version.

To see if you have this same problem, go to a shell where you could run julia and run

echo $LD_LIBRARY_PATH

If the result is nothing, then you have some other problem. If it shows something like /usr/lib64:... then you probably have the same problem I did. I’d start by looking at your shell initialization files ~/.bashrc, ~/.bash_profile, … for a line where it sets LD_LIBRARY_PATH and try commenting it out.

If your shell initialization files don’t set that variable, I’d look into whether you’re using conda or module or some other software management tool that might be setting LD_LIBRARY_PATH somehow.

You may run into a clash where some other program you use needs to set LD_LIBRARY_PATH, in which case you’ll have to figure out some other fix.

1 Like
6

Running versioninfo() in the Julia REPL (or using InteractiveUtils: versioninfo; versioninfo() in a script) prints significant environment variables, including LD_LIBRARY_PATH (I think), among other things.

Also, to be perfectly clear, LD_LIBRARY_PATH misuse is user error. Or system administrator error. Similarly with LD_PRELOAD, etc.

1 Like