Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Too late: Please, do not update glibc to 2.11 too fast...

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Too late: Please, do not update glibc to 2.11 too fast...
  • Date: Tue, 10 Nov 2009 03:10:21 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page