Bug 667 – libstdc++-2.9.0 depends on GLIBC 2.1

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 667 - libstdc++-2.9.0 depends on GLIBC 2.1

Summary:	libstdc++-2.9.0 depends on GLIBC 2.1

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Raw Hide
Classification:	Retired
Component:	egcs (Show other bugs)
Sub Component:
Version:	1.0
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Nalin Dahyabhai
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	1999-01-01 20:29 EST by jehamby
Modified:	2008-05-01 11:37 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	1999-01-04 18:58:25 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description jehamby 1999-01-01 20:29:05 EST

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...

Comment 1 Cristian Gafton 1999-01-04 12:46:59 EST

stuff build against glibc 2.1 is not backwards compatible with glibc
2.0. Period.

Comment 2 Aleksey Nogin 1999-01-04 18:02:59 EST

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.

Comment 3 jehamby 1999-01-04 18:17:59 EST

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.

Comment 4 Cristian Gafton 1999-01-04 18:58:59 EST

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.

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