Bug 103316 - libtool adds an RPATH for /usr/lib64 on ppc64
Summary: libtool adds an RPATH for /usr/lib64 on ppc64
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: powerpc Linux
high
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 101028
TreeView+ depends on / blocked
 
Reported: 2003-08-28 19:26 UTC by Joe Orton
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: 1.5-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-27 10:51:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Joe Orton 2003-08-28 19:26:04 UTC
When relinking a library during the httpd install on ppc64, libtool is adding an
RPATH for /usr/lib64.  I am guessing this is because libtool is picking up:

sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"

on this platform (at least /usr/bin/libtool has this)

which is surely wrong, since this is a libdir=/usr/lib64 platform?

For my libraries built using "libtool --mode=link ... -rpath $libdir ..."
no other platform is adding an RPATH during relinking except ppc64.

Has the wrong libtool got installed in the buildroot or something?

This is going to be a swine to work around.

Comment 1 Joe Orton 2003-10-24 10:55:26 UTC
As mentioned in bug 98616, and it happens when linking not just relinking:

  # Find out which ABI we are using (multilib Linux x86_64 hack).
  libsuff=
  case "$host_cpu" in
  x86_64*|s390x*)   ### what no ppc64?

Can you fix this for Fedora?

Comment 2 Joe Orton 2003-10-24 11:12:20 UTC
The line needs to be

  x86_64*|s390x*|powerpc64*)

not ppc64*, confusingly.

Comment 3 Jens Petersen 2003-10-28 14:13:59 UTC
Should get fixed in libtool-1.5-8.  Thanks :)

Comment 4 Joe Orton 2003-11-27 10:51:29 UTC
Looks good to me, thanks Jens.


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