Bug 98616 - libtool has wrong sys_lib_search_path_spec on x86_64
libtool has wrong sys_lib_search_path_spec on x86_64
Status: CLOSED DUPLICATE of bug 138742
Product: Red Hat Raw Hide
Classification: Retired
Component: libtool (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-07-04 20:25 EDT by Harald Welte
Modified: 2007-04-18 12:55 EDT (History)
1 user (show)

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

Attachments (Terms of Use)
patch (can be used via %patch16 -p0 in libtool-1.5-3.src.rpm) (1.00 KB, patch)
2003-07-04 20:26 EDT, Harald Welte
no flags Details | Diff

  None (edit)
Description Harald Welte 2003-07-04 20:25:05 EDT
Description of problem:

when libtool is trying to resolve inter-library dependencies, it is looking in
sys_lib_search_path_spec to find those libraries.  Unfortunately, even on
x86_64, the path is set to "/usr/lib /lib /usr/local/lib", instead of
"/usr/lib64 /lib64 /usr/local/lib64".  Thus libtool assumes that the shared
version of the dependant library is not installed, and build a static lib instead :(

Version-Release number of selected component (if applicable):

How reproducible:

I've encountered the problem while trying to build transcode plugins, but it is
quite a generic error.

I've built a new libtool RPM including a patch from SuSE SLES8 (x86_64) that
fixes this issue.  I'm going to attach the patch to this bug report
Comment 1 Harald Welte 2003-07-04 20:26:56 EDT
Created attachment 92759 [details]
patch (can be used via %patch16 -p0 in libtool-1.5-3.src.rpm)
Comment 2 Jens Petersen 2003-07-08 08:35:03 EDT
Thank you for the report.

I just note that at least /usr/bin/libtool is using lib64 on x86_64.
Also right after the 2nd hunk of your patch in libtool.m4 I see code like:

  # Find out which ABI we are using (multilib Linux x86_64 hack).
  case "$host_cpu" in
    echo '[#]line __oline__ "configure"' > conftest.$ac_ext
    if AC_TRY_EVAL(ac_compile); then
      case `/usr/bin/file conftest.$ac_objext` in
    rm -rf conftest*
  sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff}"
  sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff}

which should admittedly should be extended to ppc at least, but is that not
sufficient, or am I missing something?
Comment 3 Daniel Reed 2004-08-20 00:22:35 EDT
I see a few references to x86_64-specific libraries in /usr/lib/gcc,
but otherwise rawhide's /usr/bin/libtool appears to list /usr/lib64
for $sys_lib_search_path_spec. Please re-open if you encounter any
similar problems in the future. Thanks.
Comment 4 Joe Orton 2005-01-20 06:18:44 EST
This bug has re-appeared.

bash-3.00# uname -m
bash-3.00# ./libtool --version
ltmain.sh (GNU libtool) 1.5.10 (1.1220.2.130 2004/09/19 12:13:49)

Copyright (C) 2003  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
bash-3.00# grep ^sys_lib_dlsearch_path libtool
sys_lib_dlsearch_path_spec="/lib /usr/lib include ld.so.conf.d/*.conf "
sys_lib_dlsearch_path_spec="/lib /usr/lib include ld.so.conf.d/*.conf "
sys_lib_dlsearch_path_spec="/lib /usr/lib include ld.so.conf.d/*.conf "

it breaks the subversion "make check" since test libraries pick up
RPATHs of /usr/lib64 which they would not if the variable was set
Comment 5 Joe Orton 2005-01-20 06:23:07 EST
The special $libsuff stuff seems to have completely disappeared from
libtool.m4! This is a nasty regression.
Comment 6 Daniel Reed 2005-01-20 11:01:26 EST
The old multilib patch was not acceptable for upstream Libtool, and a new one is
being developed. libtool-1.5.10-1.1 in dist-fc4-scratch includes a new,
experimental multilib patch.

*** This bug has been marked as a duplicate of 138742 ***

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