Bug 154277

Summary: Incorrect library path links static libstdc++ in user shared libraries
Product: Red Hat Enterprise Linux 4 Reporter: Liviu Nicoara <nicoara>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 4.0   
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-04-08 23:10:51 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:

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