search

drobilla / serd

A lightweight C library for RDF syntax
https://gitlab.com/drobilla/serd
ISC License
86 stars 15 forks source link

Cannot find shared object file #15

Closed wouterbeek closed 6 years ago

wouterbeek commented 6 years ago

I like to pull and compile the latest and greatest Serd version; I compile it with ./waf configure, ./waf, and sudo ./waf install. Directly after completing this sequence of commands, Serdi works fine. But after a while I get the following error:

$ serdi
serdi: error while loading shared libraries: libserd-0.so.0: cannot open shared object file: No such file or directory

The library file is located in what seems to be a normal location:

$ find /usr/ -name libserd-0.so.0
/usr/local/lib/libserd-0.so.0

Recompiling fixes the issue, but only temporarily. I'm using Fedora 27.

Any ideas on what might cause this?

drobilla commented 6 years ago

That's... odd. Can't be a code issue. It's possible something is changing in your environment which removes /usr/local/lib from your library path. Try running ldd on serdi next time it happens?

drobilla commented 6 years ago

(Note you could work around this by configuring with --static-progs if you're on a POSIX system, but it might be a good idea to figure what's going on here because presumably other things that use the serd library like HDT would break as well)

wouterbeek commented 6 years ago

After restarting my laptop I observe this again (notice the not found):

$ serdi
serdi: error while loading shared libraries: libserd-0.so.0: cannot open shared object file: No such file or directory
$ ldd ~/git/serd/build/serdi 
    linux-vdso.so.1 (0x00007fffe21fa000)
    libserd-0.so.0 => not found
    libm.so.6 => /lib64/libm.so.6 (0x00007f595b145000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f595ad62000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f595b49a000)

After compiling and installing Serd again, this is (temporarily) fixed:

$ ldd build/serdi
    linux-vdso.so.1 (0x00007ffed23df000)
    libserd-0.so.0 => /usr/local/lib/libserd-0.so.0 (0x00007f37b5d17000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f37b59c2000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f37b55df000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f37b5f2c000)

/ust/local/lib is not on my linker path (neither before nor after compiling and installing Serd):

$ ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/lib64/atlas:
/usr/lib64/bind99:
/usr/lib64/iscsi:
/usr/lib64/R/lib:
/usr/lib64/tcl8.6:
/lib:
/lib64:
/lib/i686: (hwcap: 0x0002000000000000)
/lib/sse2: (hwcap: 0x0000000000000001)
/lib64/sse2: (hwcap: 0x0000000000000001)
/lib64/tls: (hwcap: 0x8000000000000000)
wouterbeek commented 6 years ago

Adding /usr/local/lib to a file in /etc/ld.so.conf.d and running sudo ldconfig permanently fixes this.

Could it be that sudo ./waf install changes the linker path temporarily?

drobilla commented 6 years ago

Sort of. It runs ldconfig specifically for the directory the serd library is installed in (if DESTDIR is not given, anyway), so if that's not in your configured library path, the next time you run ldconfig on its own it will remove any libraries from /usr/local/lib.

Alternatively, it could just not run ldconfig whatsoever, but then it just wouldn't work at all and I'd rather not hear constant "bug" reports from people who didn't run ldconfig :)

I'm going to close this since it's general system/library stuff and I can't think of anything reasonable to do that would avoid it.