Can't load a shared library

I have a shared library liba.so which requires /lib/x86_64-linux-gnu/libcurl.so to run.

bash> ldd liba.so
...
libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f319ee74000)
...

I use ccall to call a function in liba.so, but it produces an error below:

ERROR: could not load library "/home/xxx/.../lib/liba.so"
/home/xxx/julia/bin/../lib/julia/libcurl.so: version `CURL_OPENSSL_4' not found (required by /home/xxx/.../lib/liba.so)

It seems that the required shared library is linked to the libcurl.so provided by Julia. What should I do to load the shared library liba.so?

You may be able to fix this by setting the rpath for your library, either in the link stage of building it or with patchelf. I once asserted that this sort of thing would not work, but @staticfloat has made admirable steps towards proving me wrong, so perhaps he can provide more complete advice.

Thank you for reply. I run patchelf --set-rpath /lib/x86_64-linux-gnu liba.so, and the same error occurs.
I provide a simple example here.
The file a.c:

#include <stdio.h>
#include <curl/curl.h>
void test()
{
  printf("%s\n", curl_version());
}

and compile it with gcc -shared -fPIC a.c -lcurl -Wl,-rpath=/lib/x86_64-linux-gnu -o liba.so
In Julia, I run Libc.Libdl.dlopen("liba.so"), and throw the above error still:

ERROR: could not load library "liba.so"
/home/xxx/julia/bin/../lib/julia/libcurl.so: version `CURL_OPENSSL_4' not found (required by liba.so)

I experimented a bit but haven’t been able to get runpath/deepbind to work as advertised (IIUC) for this case either.

Another approach is to use the environment variable LD_PRELOAD=/lib/x86_64-linux-gnu/libcurl.so in the shell where you run Julia (and hope that nothing in your Julia environment really needs, or pointlessly checks for, the other version if it can’t find it).

But the most robust solution (if you have the time to work it out) would probably be to compile your library using BinaryBuilder so that it has a better chance at portable compatibility.

1 Like

Thank you. It works fine after I modify the environment variable LD_PRELOAD.

I compare the output with that calling from Python’s ctypes, and they are equal. There seems no bug.