This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 154277 - Incorrect library path links static libstdc++ in user shared libraries
Incorrect library path links static libstdc++ in user shared libraries
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc (Show other bugs)
4.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-08 19:00 EDT by Liviu Nicoara
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-08 19:10:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Liviu Nicoara 2005-04-08 19:00:20 EDT
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 19:10:51 EDT
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 19:43:17 EDT
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.