| Summary: | Missing libstdc++.so.6.0.13 for use with GCC 4.4 preview in 5.6 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | derekbr |
| Component: | gcc44 | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-tools-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.6 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-05 15:39:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
derekbr
2011-03-28 19:16:59 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. |