Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Hi,

glibc-2.11 has been released recently and you might be tempted to update our 
spell. Well, .. oh ... fricked: Ladislav did it already. Hm. Uhm. Well. What 
I was about to say:

1. I am working on updating the SGML Alpha port. That means adding the 
spin-off glibc-ports for non-x86 architecture and an assload of patches, by 
way of the gentoo patchset, to battle against the ignorance of glibc 
developers towards such unimportant architectures like ARM (which is not 
officially an arch supported/maintained by glibc upstream anymore!). 

2. glibc-ports people need to catch up with funny stuff in latest glibc to 
make a matching release of glibc-ports-2.11 . They are not there yet, as I 
see from reading the libc-ports list.

3. Likewise, as even glibc-ports won't manage to provide working Alpha 
support in release version 2.11, I depend on the gentoo patchset (which 
largely is the debian patchset, as alpha fixes are concerned) to get a 
working glibc at all. The friendly gentoo guy said he is going to check out 
glibc 2.11 in the near future, but, well, it's not been that long that 2.10.1 
works.

4. One might indeed consider ditching vanilla glibc as upstream. Eglibc is 
getting some time in the sunshine now that debian switches to it... might be 
reasonable to use that as a buffer between our users and the not always too 
human-friendly upstream actions. I mean, I am a bit frightened by the kind of 
patches that are needed to transform vanilla glibc into something barely 
usable. And indeed the lack of stable release series... like, with bugfixes 
and minimal other hacking, is not nice for something that essential.


Anyhow, I popped in to tell that I am close to getting our alpha port working 
again with glibc-2.10.1 ... and now see that that is already p0wn3d by 2.11 
entering the grimoire. The kind of discussions on libc-ports suggests that it 
is non-trivial to follow the changes in glibc... Now we could have a debate 
over whether such esoteric non-x86 setups should hinder the progress of the 
important SMGL world... or figure out a way to make it work nicely together.
Personally, I would think it fair to wait for glibc-ports to appear before 
upgrading to a new glibc version. glibc + glibc-ports is what earlier 
versions of glibc represented.

Since there already is alpha-specific code needed in the spell scripts (as 
for x86-64, too); it might be not too bad to use version 2.10.1 for that arch 
and 2.11 on others. What bothers me is that that important spell already is 
cluttered, with NTPL and non-NPTL, CVS version (do we really need that?)... 
then various if branches for SMGL_COMPAT_ARCH ...

It would already help to drop non-NPTL and CVS ... perhaps then I can better 
stand having only the multi-version switch based on architecture. So, who 
uses those two options? Do we support kernel 2.4 (for non-NPTL)?

Flames, anyone? Man, it's late here... Perhaps I shouldn't even send this 
babbling, but when I already spent all the time deep into the night to write 
it... trying to get that fricking bleeding edge glibc crap to work... gah, 
I'm drifting off again...


Alrighty then,

Thomas.

Attachment: signature.asc
Description: PGP signature