glibc 2.1.94 CVS merge, packages on the way, ABI breakage :(
Hi,
I've merged pehc CVS with glibc 2.1.94 release (no more tracking CVS for me, too much pain).
The patch is clean enough that I'm able to just add it to the Debian glibc 2.1.94 source package. So I will build that overnight (hopefully) and upload it sometime soon.
For the time being there is a tarball at ftp://puffin.external.hp.com/pub/parisc/binaries/userspace/glibc-2.1.94-20001003.tar.gz
But! Beware! It *will* break your system. Somehow, the versions of a bunch of symbols in libm.so.6 reverted to GLIBC_2.0 from GLIBC_2.2 (don't ask me how this happened, math/Versions is still exactly the same... I think our 2.1.92 had a bug in the script that generates the version maps) and as a result, anything that links with libm will not work. This includes fun things like perl, awk, some parts of shellutils, etc. etc.
Sorry about this, but I guess we have no choice, our old libm.so was broken.
I'm rebuilding perl, shellutils, and awk and expect to have new packages on pehc real soon now. (perl's version will be 5.005.03-7.2, shellutils and awk will be similarly bumped)
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.
Quoted 2 lines · David Huggins-Daines
But! Beware! It *will* break your system. Somehow, the versions of a bunch of symbols in libm.so.6 reverted to GLIBC_2.0 from GLIBC_2.2
You never should have GLIBC_2.0 symbols. The shlib-versions file should have GLIBC_2.2 as the earliest version (third column).
Signature · 3 lines
---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
Quoted 2 lines · Ulrich Drepper
You never should have GLIBC_2.0 symbols. The shlib-versions file should have GLIBC_2.2 as the earliest version (third column).
Ah, I see what the problem is. It seems that it is my fault :(
I take it that libc.so, libm.so, and ld.so should all be versioned with GLIBC_2.2 as the base, then?
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.
Quoted 2 lines · David Huggins-Daines
I take it that libc.so, libm.so, and ld.so should all be versioned with GLIBC_2.2 as the base, then?
Every single DSO. There is no compatibility to be preserved.
Signature · 3 lines
---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
Quoted 6 lines · Ulrich Drepper
Quoted 2 lines · David Huggins-Daines
I take it that libc.so, libm.so, and ld.so should all be versioned with GLIBC_2.2 as the base, then?
Every single DSO. There is no compatibility to be preserved.
Okay, yes, you're right. Unfortunately we've built a bunch of binaries against our broken libc, so it will all have to be rebuilt, because all binaries expect to see GLIBC_2.0 and GLIBC_2.1 versions.
But I guess this is the right thing to do, since we really do not want any of the compatibility cruft bloating our libc.
HP people note: Yes it looks like we have to rebuild everything. I think I can get things up again rather quickly, as I just need to build a static toolchain and then relink all the packages that are sitting around built on my A180. We will have to clear out the archive in pehc:/pub/debian-hppa though.
I am not very pleased with symbol versioning at the moment :(
Signature · 2 lines
[email protected], http://www.linuxcare.com/ Linuxcare. Support for the revolution.