Bug 98616

Summary: libtool has wrong sys_lib_search_path_spec on x86_64
Product: [Retired] Red Hat Raw Hide Reporter: Harald Welte <laforge>
Component: libtoolAssignee: Daniel Reed <djr>
Status: CLOSED DUPLICATE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: jorton, noloader
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-20 16:01:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch (can be used via %patch16 -p0 in libtool-1.5-3.src.rpm) none

Description Harald Welte 2003-07-05 00:25:05 UTC
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-05 00:26:56 UTC
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 12:35:03 UTC
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).
  libsuff=
  case "$host_cpu" in
  x86_64*|s390x*)
    echo '[#]line __oline__ "configure"' > conftest.$ac_ext
    if AC_TRY_EVAL(ac_compile); then
      case `/usr/bin/file conftest.$ac_objext` in
      *64-bit*)
        libsuff=64
        ;;
      esac
    fi
    rm -rf conftest*
    ;;
  *)
    ;;
  esac
  sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff}"
  sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff}
/usr/local/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 04:22:35 UTC
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 11:18:44 UTC
This bug has re-appeared.

bash-3.00# uname -m
x86_64
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
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
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 "
bash-3.00#

it breaks the subversion "make check" since test libraries pick up
RPATHs of /usr/lib64 which they would not if the variable was set
correctly.

Comment 5 Joe Orton 2005-01-20 11:23:07 UTC
The special $libsuff stuff seems to have completely disappeared from
libtool.m4! This is a nasty regression.

Comment 6 Daniel Reed 2005-01-20 16:01:26 UTC
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 ***