Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 209930 - libtool-ltdl searches in relative paths
libtool-ltdl searches in relative paths
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Karsten Hopp
: Security
Depends On:
  Show dependency treegraph
Reported: 2006-10-08 09:17 EDT by Enrico Scholz
Modified: 2010-01-25 08:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-23 12:12:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2006-10-08 09:17:47 EDT
Description of problem:

libltdl seems to be built in some way which results into a
library-searchpath containing relative paths:


--- victim.c ----
#include <ltdl.h>

int main() {
        lt_dlhandle     h = lt_dlopenext("foo");
        void            (*f)(void) = lt_dlsym(h, "foo");

--- 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):

Comment 1 Karsten Hopp 2006-11-06 08:57:05 EST
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.

Comment 2 Karsten Hopp 2006-11-06 10:55:14 EST
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 !
Comment 3 Lubomir Kundrak 2006-11-20 15:13:10 EST
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?
Comment 4 Karsten Hopp 2007-01-23 12:12:28 EST
fixed in the latest rawhide package
Comment 5 Tomas Hoger 2010-01-25 08:31:41 EST
Upstream commit, noted for posterity:

Note You need to log in before you can comment on or make changes to this bug.