Bug 140977 - wrong sys_lib_search_path_spec in /usr/bin/libtool
Summary: wrong sys_lib_search_path_spec in /usr/bin/libtool
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: libtool
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Alexandre Oliva
QA Contact: David Lawrence
: 143889 145920 (view as bug list)
Depends On:
Blocks: 137160
TreeView+ depends on / blocked
Reported: 2004-11-27 10:11 UTC by Joe Orton
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2005-06-09 12:27:44 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:234 normal SHIPPED_LIVE libtool bug fix update 2005-06-09 04:00:00 UTC

Description Joe Orton 2004-11-27 10:11:26 UTC
Description of problem:
The sys_lib_search_path_spec in /usr/bin/libtool references the wrong
version of GCC.

This seems to mean at least that it can't build shared C++ libraries.

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

How reproducible:

Steps to Reproduce:
$ echo 'void foo(void) {}' > foo.cpp
$ /usr/bin/libtool --mode=compile --tag=CXX g++ -c foo.cpp
 g++ -c foo.cpp  -fPIC -DPIC -o .libs/foo.o
 g++ -c foo.cpp -o foo.o >/dev/null 2>&1
$ /usr/bin/libtool --mode=link --tag=CXX g++ -o libfoo.la -rpath
/usr/lib foo.lo
g++ -shared -nostdlib
/usr/lib/gcc/i386-redhat-linux/3.4.1/crtbeginS.o  .libs/foo.o 
-L/usr/lib/gcc/i386-redhat-linux/3.4.1/../../.. -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc/i386-redhat-linux/3.4.1/crtendS.o
/usr/lib/gcc/i386-redhat-linux/3.4.1/../../../crtn.o  -Wl,-soname
-Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
g++: /usr/lib/gcc/i386-redhat-linux/3.4.1/../../../crti.o: No such
file or directory
g++: /usr/lib/gcc/i386-redhat-linux/3.4.1/crtbeginS.o: No such file or
directoryg++: /usr/lib/gcc/i386-redhat-linux/3.4.1/crtendS.o: No such
file or directory
g++: /usr/lib/gcc/i386-redhat-linux/3.4.1/../../../crtn.o: No such
file or directory

Mitigating circumstances:
Usually libtool is used by creating a new libtool script not the
pre-built one, it's only the pre-built one which suffers from this issue.

Recommend to just rebuild libtool-1.5.6 for RHEL4.

Comment 1 Daniel Reed 2005-01-03 23:12:43 UTC
*** Bug 143889 has been marked as a duplicate of this bug. ***

Comment 2 Jairo Medina 2005-01-18 16:55:47 UTC
Can you release a rebuilt rpm fixing this problem for FC3 ?
I have an application that compiles in other distributions but not in FC3.


Comment 3 Joe Orton 2005-02-09 14:06:06 UTC
*** Bug 145920 has been marked as a duplicate of this bug. ***

Comment 4 Antonio Zugaldia 2005-03-03 09:35:16 UTC
I think that this issue is connected with Bug 138742, that has also problems in
the sys_lib_search_path_spec variable in the generated libtool.

At least I get the same errors when trying to compile packages in RHEL 4 in x86_64:

/usr/lib/libpopt.so: could not read symbols: File in wrong format

I haven't been able to install the binary packages from Rawhide in RHEL, neither
to build the source packages.

Comment 5 Jay Turner 2005-04-16 17:50:56 UTC
Fix confirmed with libtool-1.5.6-4.EL4.1 which will be released as part of
RHBA-2005:234.  Moving to PROD_READY.

Comment 6 Tim Powers 2005-06-09 12:27:44 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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