Red Hat Bugzilla – Bug 667
libstdc++-2.9.0 depends on GLIBC 2.1
Last modified: 2008-05-01 11:37:48 EDT
Installing the libstdc++.2.9.0 RPM didn't require me to upgrade my glibc, even though it should require GLIBC 2.1, as evidenced by the many symbols that reference it: $ nm /usr/lib/libstdc++.so.2.9.0 | grep GLIBC_2.1 U _IO_do_write@@GLIBC_2.1 U _IO_file_attach@@GLIBC_2.1 U _IO_file_close_it@@GLIBC_2.1 U _IO_file_fopen@@GLIBC_2.1 U _IO_file_init@@GLIBC_2.1 U _IO_file_overflow@@GLIBC_2.1 U _IO_file_seekoff@@GLIBC_2.1 U _IO_file_setbuf@@GLIBC_2.1 U _IO_file_sync@@GLIBC_2.1 U _IO_file_underflow@@GLIBC_2.1 U _IO_file_write@@GLIBC_2.1 U _IO_file_xsputn@@GLIBC_2.1 U _IO_getline_info@@GLIBC_2.1 U _IO_proc_close@@GLIBC_2.1 U _IO_proc_open@@GLIBC_2.1 U _sys_nerr@@GLIBC_2.1 U fclose@@GLIBC_2.1 U sys_nerr@@GLIBC_2.1 I had already upgraded GLIBC because the KDE packages required it for other reasons, so I haven't tried to link against libstdc++.so.2.9.0 with the old library, but I expect it could crash, especially if you call I/O methods. You should upgrade the dependency information in the EGCS RPM to make it explicit that GLIBC 2.1 is required to install libstdc++. This brings me to a related point: I had already compiled EGCS 1.1.1 from source against GLIBC 2.0, then discovered that my C++ binaries crashed when I installed the libstdc++ RPM from RawHide. Similarly, new binaries wouldn't link to code which had been compiled against the old EGCS headers. The culprit seems to be the lines in /usr/include/g++/streambuf.h which check the GLIBC version: #if _G_IO_IO_FILE_VERSION == 0x20001 These actually cause a different (and incompatible) library to be built on GLIBC 2.0 and GLIBC 2.1 systems. This is really unfortunate, but I guess the best thing to do is make it explicit in the RPM that libstdc++-2.9.0 requires GLIBC 2.1, especially since nobody has yet shipped a Linux distribution which includes libstdc++.so.2.9.0 compiled against GLIBC 2.0. Unfortunately, people who compile EGCS 1.1.1 from source (or install Linux binaries from others) risk having to recompile all of their C++ code when they upgrade to RawHide, so this becomes a big documentation problem as well! What a mess...
stuff build against glibc 2.1 is not backwards compatible with glibc 2.0. Period.
I believe that was the whole point - stuff build against glibc 2.1 is not backwards compatible with glibc 2.0, so it should have Requires: glibc >= 2.1 in the SPEC file.
That was exactly my point - stuff build against glibc 2.1 is not backwards compatible with glibc 2.0, so it should have Requires: glibc >= 2.1 in the SPEC file.
glibc 2.1 was not yet released; starting to insert dependencies now will only hurt things (get people confused as to 'where is glibc 2.1 released'?); this is rawhide after all.