Re: libtool does not recognize "/usr/lib64" as default location for libraries

[Olly Betts]

On 2010-06-23, Jirka Hladky <address@hidden> wrote:
> we have run into a problem where package developed on Debian and packaged for 
> Fedora had rpath included in binaries. This is bad and forbidden by rpm rules 
> (rpmlint will mark it as an error).
>
> After long discussion with upstream and Fedora packagers mailing list we have 
> found a reason for this bug: libtool does not consider "/usr/lib64" as 
> default 
> location for libraries. On Fedora for x86_64 it's however default location 
> for 
> libraries.
>
> We would kindly ask you to incorporate patch to add "/usr/lib64"  as default 
> location for libraries to the official source code. 
>
> http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a-
> rpath.patch?content-type=text%2Fplain&view=co
>
> This will enable packages developed on other than Fedora systems (with 
> included libtool script) to be compiled properly on Fedora.

The underlying issue here is that libtool parses ld.so.conf itself, but
ldconfig searches some directories in addition to those listed in the
config file, so libtool has a list of those default directories which it
adds to those it finds in the config file.  But the default list varies -
on Fedora the list includes /usr/lib64 (presumably only for 64 bit archs
though).

Fixing this by adding /usr/lib64 unconditionally is technically wrong
since not all distros search /usr/lib64 - e.g. Debian and Ubuntu use /lib
and /usr/lib on both 32 and 64 bit archs - and 32 bit archs presumably
don't for any distro.  A user specifying --prefix=/usr/lib64 on a machine
where that would need an rpath wouldn't get one (probably not a huge issue
in practice), but more of a concern is that there may also be other
default directories.  For example, on x86-64 Ubuntu karmic libtool 2.2.6
misses the following directories which ldconfig searches by default:

/lib32
/usr/lib32
/lib32/i486
/lib32/i686
/lib32/i586
/usr/lib32/sse2
/lib32/i686/cmov

Overall it seems to me to be more reliable and cleaner to ask ldconfig
what directories it thinks it is looking in rather than parsing its config
files and guessing at what others it might search by default.

I posted just such a patch exactly 3 years ago today (coincidentally) -
here's the thread:

http://thread.gmane.org/gmane.comp.gnu.libtool.general/8339/focus=8345

Back then Ralf said "Olly's solution should not be forgotten, though", but
it seems it has been.

I've been using this code in Xapian to override libtool's version for a
couple of years now, with no reported problems.

The only downside is that it can be quite slow to get the list from
ldconfig (I haven't investigated why or if this could be improved - it's
interesting that it always seems quick if run a second time which suggests
either a cache issue, or that there's a cached value being updated), but
the speed of the current approach seems greatly outweighed by the wrong
answers it gives.

As I said in the original thread, if the patch is wanted I'm happy to
update it for current libtool and write a ChangeLog entry.

Cheers,
    Olly