Description of problem: libltdl seems to be built in some way which results into a library-searchpath containing relative paths: E.g. --- victim.c ---- #include <ltdl.h> int main() { lt_dlinit(); lt_dlhandle h = lt_dlopenext("foo"); void (*f)(void) = lt_dlsym(h, "foo"); (*f)(); } ---- --- foo.c --- void foo() { write(1, "got you...\n", 11); } ---- | $ gcc -g3 -O0 victim.c -o bin/victim -lltdl | $ libtool --mode=compile gcc -g3 -O0 -c foo.c | $ libtool --mode=link gcc -rpath `pwd`/bin/nosegneg -module -avoid-version -o foo.la foo.lo | $ libtool --mode=install install foo.la `pwd`/bin/hwcap/foo.la | | $ cd bin | $ strace ./victim | open("/lib/foo.la", O_RDONLY) = -1 ENOENT (No such file or directory) | open("/usr/lib/foo.la", O_RDONLY) = -1 ENOENT (No such file or directory) | open("hwcap/foo.la", O_RDONLY) = -1 ENOENT (No such file or directory) | open("0/foo.la", O_RDONLY) = -1 ENOENT (No such file or directory) | open("nosegneg/foo.la", O_RDONLY) = 3 | ... | write(1, "got you...\n", 11got you... | ... This relative paths are in libltdl.so: | $ strings /usr/lib/libltdl.so | grep hwc | /lib:/usr/lib:hwcap:0:nosegneg:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/qt-3.3/lib | /lib:/usr/lib:hwcap:0:nosegneg:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/qt-3.3/lib The 'mysql' and 'qt' paths do not seem to be ok either. Version-Release number of selected component (if applicable): libtool-ltdl-1.5.22-2.3
partly caused by /etc/ld.so.conf.d/kernelcap-* from the kernel-xen package which puts some varaiables instead of directories into the configfile. I have a patch to ignore everything which doesn't looks like an absolute path in /etc/ld.so.conf.d/*, but I still have 'open("foo.la", O_RDONLY)' which I'm looking for right now.
Can you try out http://people.redhat.com/karsten/libtool-1.5.22-2.7.src.rpm , please ? It should ignore the entries in /etc/ld.so.conf.d/kernelcap-* and shouldn't look in the current working directory for .la files. Please try to start some programs linked with libltdl and post any findings here. Thanks !
Would't it be better if sys_search_path[] was determined system's actual configuration at runtime? From my point of view hardcoding it and depending on build host setup makes no sense for pre-compiled binary based system. But I am unaware of a possible performance penalty, would there be any?
fixed in the latest rawhide package
Upstream commit, noted for posterity: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b3251f4d7e86d0bd4901de62cd9bcd18ddd7965a