Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154277 - Incorrect library path links static libstdc++ in user shared libraries
Summary: Incorrect library path links static libstdc++ in user shared libraries
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc
Version: 4.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-08 23:00 UTC by Liviu Nicoara
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-08 23:10:51 UTC


Attachments (Terms of Use)

Description Liviu Nicoara 2005-04-08 23:00:20 UTC
Description of problem:

When building shared libraries, g++ uses an incorrect library path which leads
to linking libstdc++.a to a user shared library.

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

$ gcc -v
Reading specs from
/build/nicoara/contrib/gcc-3.4.3-9/lib/gcc/x86_64-redhat-linux/3.4.3/specs
Configured with: ../gcc-src/configure
--prefix=/build/nicoara/contrib/gcc-3.4.3-9 --enable-shared
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++
--host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)


How reproducible:

Always.

Steps to Reproduce:

$ cat > t.cpp << EOF

#include <iostream>

EOF

$ g++ -c -fPIC t.cpp && g++ -shared -o libt.so t.o 
/package/1/em64t/utils/binutils/2.15.92.0.2-10.EL4/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a(ios_init.o): relocation
R_X86_64_32 against `std::ios_base::Init::_S_refcount' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a: could not read symbols: Bad
value
collect2: ld returned 1 exit status

  
Actual results:


Expected results:


Additional info:

The verbose output of the linking command shows the lib paths, of which of
interest are:

...
-L/usr/lib/gcc/x86_64-redhat-linux/3.4.3 
-L/build/nicoara/contrib/gcc-3.4.3-9/lib/gcc/x86_64-redhat-linux/3.4.3/../../../../lib64
...

The first one contains the libstdc++.a against which it tries to link.

Comment 1 Jakub Jelinek 2005-04-08 23:10:51 UTC
This is clearly your self-build GCC, not the one provided in RHEL4.
The packaged gcc-c++ certainly provides libstdc++.so symlink in the same path
as libstdc++.a and therefore the linker picks that up first, your testcase
compiles on RHEL4 just fine.  But for self-build GCC you are on your own
to make sure it is properly installed.

rpm -qf /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.so
gcc-c++-3.4.3-9.EL4



Comment 2 Liviu Nicoara 2005-04-08 23:43:17 UTC
Yes indeed, the compiler was built from sources coming from RedHat. We cannot
afford to replace the compiler in /usr/bin thus we built the compiler ourselves
and place it in a special location.

I would like to know what is the RedHat recommended way of building the compiler
from the sources which RedHat recommends. If our sysadmins are doing something
wrong in the way they are installing the compiler, that needs to be corrected.

I need to mention here that we built the 3.4.3 from GNU's repository and it
works just fine w/ the same test case on EL4.

If us building the compiler from your sources is not supported please let us
know so that we can pursue other avenues.

Thanks,
Liviu Nicoara


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