glibc 2.1 and potato
glibc 2.1 will be officially released in a few days time.
It will be available immediately (well, about 4 hours after for i386,
with other architectures hopefully to follow) via apt from:
'deb http://www.debian.org/%7Eespy/ glibc-2.1/binary-$(ARCH)/'. I
don't intend to upload to unstable until a) slink is released and b)
it has been decided how to deal with the libstdc++2.9 issue[0].
There are also some other libraries (besides libstdc++) that need to
be recompiled to allow new programs to link against them, such as
ncurses (and any other library that uses libio (you can tell by
looking for _IO_* symbols)), however in that case, the new libraries
will continue to work with old programs.
Some programs will cause the dynamic linker to print warnings such
as: "less: Symbol `ospeed' has different size in shared object,
consider re-linking" (that's after installing a new ncurses linked
against glibc 2.1).
I'd like a volunteer to do builds for alpha and m68k (the rest of the
architectures already use glibc 2.1).
[0] The runtime library for a glibc 2.0-based system will continue to
function on a glibc 2.1 system, but it is not possible to link new
programs against the old runtime library (it will succeed, but the
resulting binary won't work). My current plan is as follows, egcs
will be rebuilt under glibc 2.1 and will produce
'libstdc++2.9-glibc2.1' and 'libstdc++2.9-glibc-2.1-dev' from then
on, this way older packages will continue to work until we can
recompile them against the new libstdc++[1]
[1] Unlike the libstdc++2.8 -> libstdc++2.9 transition in slink,
there will be no way the older libstdc++2.9 can be made on a potato
system[2], thus we have to recompile C++-based packages so that they
don't have dependencies that can't be resolved in potato.
[2] Barring something evil like 'slink-chroot_1.0.deb'
--
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: