Bug 691540 - Missing libstdc++.so.6.0.13 for use with GCC 4.4 preview in 5.6
Summary: Missing libstdc++.so.6.0.13 for use with GCC 4.4 preview in 5.6
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc44
Version: 5.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelinek
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-28 19:16 UTC by derekbr
Modified: 2011-05-13 12:18 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-05 15:39:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description derekbr 2011-03-28 19:16:59 UTC
Description of problem:
It appears that libstdc++.so.6.0.13 is not available in RHEL5.6.  GCC 4.4.4 requires it as listed here -> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html  Since this is a preview of what is in RHEL6 I checked another system running RHEL6 and noticed that there is a libstdc++.so.6.0.13 being used by GCC 4.4.4.  I presume a libstdc++44 package should be made available with the libstdc++.so.6.0.13 file within.  There is a libstdc++44-devel package available already in RHEL5.6 but it does not contain the file in question.

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

How reproducible:
We have seen this in i686 and x86_64 platforms, but suspect it is the same in others.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
On a RHEL5.6 system I'm expecting a libstdc++44 package to be available via the yum channel, but here is what I find...
[root@lmeractest ~]# yum search libstdc++
Loaded plugins: changelog, ibm-additional-metadata, ibm-cds-plugin, ibm-house-cleaning, ibm-repository, ibm-security, ibm-
              : upgrade-oc, security
===================================================== Matched: libstdc++ =====================================================
compat-libstdc++-296.i386 : Compatibility 2.96-RH standard C++ libraries
compat-libstdc++-33.i386 : Compatibility standard C++ libraries
libstdc++-296-2.96-compat.i386 : Compatibility 2.96-RH standard C++ libraries
libstdc++.i386 : GNU Standard C++ Library
libstdc++-devel.i386 : Header files and libraries for C++ development
libstdc++44-devel.i386 : Header files and libraries for C++ development



Expected results:
In RHEL6 we see the following...
Red Hat Enterprise Linux Client release 6.0 (Santiago)
[root@cmccf00 ~]# rpm -ql libstdc++ | grep libstdc++
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.13
[root@cmccf00 ~]# ls -hal /usr/lib64/libstdc++.so.6
lrwxrwxrwx. 1 root root 19 Feb 23 04:58 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.13
[root@cmccf00 ~]# ls -hal /usr/lib64/libstdc++.so.6.0.13
-rwxr-xr-x 1 root root 971K Jul 26  2010 /usr/lib64/libstdc++.so.6.0.13

Additional info:

Comment 1 Jakub Jelinek 2011-04-05 15:39:28 UTC
The problem is that libstdc++.so has the same SONAME as it had already in GCC 3.4,
and we definitely don't want to destabilize the system libstdc++.so.6 which in RHEL5 comes from gcc 4.1.2 by bumping libstdc++ (which means trading lots of bugfixes and new features for a set of unknown bugs in the new or changed code).
That is not something customers would appreciate.

Having a different libstdc++.so.6 in some other path or giving it a different SONAME is problematic too, it moves the burden of playing with LD_LIBRARY_PATH, DT_RPATH etc. on the users, and as soon as you have multiple third party libraries with different requirements on minimum libstdc++.so.6 version it would be a nightmare.

Therefore, what gcc44-c++ does, is, it links against system -lstdc++ plus
-lstdc++_nonshared.a, which contains symbols added to libstdc++.so.6 after
the system libstdc++ release.  Thus, gcc44-c++ compiled libraries or programs
should work fine on both RHEL5 and RHEL6, but you can't just take
RHEL6 (or latest SLES or whatever other recent distro with system gcc > 4.1.x)
libraries or binaries to RHEL5 and expect them to work.  That is not what these packages are meant to solve.  And libstdc++ isn't the only problem in doing so,
e.g. gcc 4.4 compiled programs also require linker and dynamic linker features
that aren't supported in RHEL5, might very well require glibc symbols not present in RHEL5, etc.


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