Re: glibc 2.1 and potato
At 19:02 +0100 1999-02-03, Gergely Madarasz wrote:
Doesn't make much difference:
gorgo@lovi:/usr/lib$ egrep -l '_IO_std(in|out|err)' *.so | wc -l
50
Hmm... it may be something else entirely, color me clueless.
>So it is only the libstdc++ library that needs a new soname ? The others
>don't ?
There really isn't an incompatibility on the runtime level, just
compile time.
At least we don't have to go thru the whole library set change again
(rpath ? ;)) So why is libstdc++ incompatible ?
Here's some detail from the glibc FAQ:
2.21. What do I need for C++ development?
{HJ,AJ} You need either egcs 1.1 which comes directly with libstdc++ or
gcc-2.8.1 together with libstdc++ 2.8.1.1. egcs 1.1 has the better C++
support and works directly with glibc 2.1. If you use gcc-2.8.1 with
libstdc++ 2.8.1.1, you need to modify libstdc++ a bit. A patch is available
as:
ftp://alpha.gnu.org/gnu/libstdc++-2.8.1.1-glibc2.1-diff.gz
Please note that libg++ 2.7.2 (and the Linux Versions 2.7.2.x) doesn't work
very well with the GNU C library due to vtable thunks. If you're upgrading
from glibc 2.0.x to 2.1 you have to recompile libstdc++ since the library
compiled for 2.0 is not compatible due to the new Large File Support (LFS)
in version 2.1.
{UD} But since in the case of a shared libstdc++ the version numbers should
be different existing programs will continue to work.
2.27. What needs to be recompiled when upgrading from glibc 2.0 to glibc
2.1?
{AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
that have been linked against glibc 2.0 will continue to work.
If you compile your own binaries against glibc 2.1, you also need to
recompile some other libraries. The problem is that libio had to be
changed and therefore libraries that are based or depend on the libio
of glibc, e.g. ncurses or slang, need to be recompiled. If you
experience strange segmentation faults in your programs linked against
glibc 2.1, you might need to recompile your libraries.
Another problem is that older binaries that were linked statically against
glibc 2.0 will reference the older nss modules (libnss_files.so.1 instead of
libnss_files.so.2), so don't remove them. Also, the old glibc-2.0 compiled
static libraries (libfoo.a) which happen to depend on the older libio
behavior will be broken by the glibc 2.1 upgrade. We plan to produce a
compatibility library that people will be able to link in if they want
to compile a static library generated against glibc 2.0 into a program
on a glibc 2.1 system. You just add -lcompat and you should be fine.
The glibc-compat add-on will provide the libcompat.a library, the older
nss modules, and a few other files. Together, they should make it
possible to do development with old static libraries on a glibc 2.1
system. This add-on is still in development. You can get it from <URL>
but please keep in mind that it is experimental.
--
Joel Klecker (aka Espy) <URL:http://web.espy.org/>
<URL:mailto:jk@espy.org> <URL:mailto:espy@debian.org>
Debian GNU/Linux PowerPC -- <URL:http://www.debian.org/ports/powerpc/>
Reply to: