This is the mail archive of the
mailing list for the glibc project.
Re: glibc2.1 not binary compatible with 2.0
- To: firstname.lastname@example.org
- Subject: Re: glibc2.1 not binary compatible with 2.0
- From: Mark Kettenis <email@example.com>
- Date: Wed, 14 Apr 1999 21:34:05 +0200 (MET DST)
- CC: firstname.lastname@example.org, email@example.com
- References: <199904141813.LAA24336@dodgson.caltech.edu>
Date: Wed, 14 Apr 1999 11:13:16 -0700
From: "Glenn W. Bach" <firstname.lastname@example.org>
Has there been any progress in figuring out why 2.0 binaries aren't
compatible with 2.1 libs?
A few bugs have been found. See the problem database
(http://www-gnats.gnu.org:8080) for more details.
If there is any way we can help test this, let me know, because we have
several programs that are affected. At first I thought it might be because
we were using the old libstdc++, but even compiling with egcs 1.0.3 and
libstdc++.so.2.8 we get the same problem, ie. a program compiled on RedHat
5.2 with glibc2.0, egcs 1.0.3, and libstdc++.so.2.8 will not run on RedHat
beta6 with glibc2.1. It immediately seg-faults.
You cannot really expect binary compatibility for C++ programs.
However, if you have a program built on a glibc2.0 system with egcs
1.0.3 and the libstcd++.so.2.8 that came with egcs 1.0.3, it should
work on a glibc2.1 system where you recompiled the same
libstdc++.so.2.8 (thus again the one that came with egcs 1.0.3,
recompiled on your glibc2.1 system with egcs 1.0.3). If this is not
the case it may be a bug in glibc2.1. Try to find where it segfaults
by using gdb and/or provide strace output, and try to create a small
test program that exposes the bug. Without this information we cannot
really do anything to find a solution.