glibc 2.6 question

Moritz Heiber moe at lunar-linux.org
Mon Sep 24 00:29:54 CEST 2007


Okay, a quick followup on all glibc related update questions:

I'd love to bump glibc. Infact, we really have to bump it. Applications
are starting to break because we're using a very old glibc. Yet, there
are two things that need to be done in order for glibc to be bumped:

1) We need a new kernel-headers-2.6 module. Right now, there's a module
in crater/ that packs up your current kernel sources, sanitizes them
and puts them into /usr/include/ ... which is what we need basically.
The problem is: the headers have to match the ones glibc is compiled
against. Thus I propose that we pack up our new headers alongside the
glibc bump and put it on our servers. That way, people updating glibc
will also get the latest kernel headers which we prepared.

2) glibc's current locale chooser is way outdated. It doesn't cover any
UTF-8 encoded locales nor a wide range of asian or african languages.
While I can live with the asian/african language support (sorry,
Asia/Africa) UTF-8 is slowly crawling t'wards being an accepted
standard .. (I'm even thinking about having it as our default
encoding .. but thats another story). Now, there's two way to solve
this issue:

a) Rewrite the chooser to support the current language codebase. This
would require somebody to dig into the languages glibc currently
supports and write a new chooser for it. I could point you into the
right direction for that.

b) Write a completely new chooser from scratch that takes the supported
languages codes from a file inside the glibc tarball and generates a
chooser based on that. I lack the skills to do this .. but it shouldn't
be too difficult .. parsing the file in question is a simple perl
statement (Jon or Auke already showed me I think) .. and after that its
matching the right country codes to the descriptions. Looking for the
right descriptions shouldn't be too hard .. but obviously it takes some
effort and time to do this.

Either solution is MANDATORY before with bump the glibc module from
my point of view. If we don't do it this time its probably going to be a
long jump until we're forced to go along with another update .. if we're
going for the bump now .. we should take the right path.

Thats it.

Moritz

On Sun, 9 Sep 2007 12:46:36 +0200
Jean-Michel Bruenn <jean.bruenn at ip-minds.de> wrote:

> Hello,
> 
> i'm working at the moment on the glibc-2.6 module, on some websites i
> read that users have problems getting it running on 2.4 Kernels.
> Anyone here running 2.4 and tested glibc-2.6 yet?
> 
> If it's really not working with 2.4 Kernels, we would need two glibc
> versions in moonbase, one for compatibility with 2.4 kernels and one
> actual. (glibc-old (2.3.6 for 2.4 kernels) and glibc (2.6.1, for 2.6
> kernels).
> 
> anyone could check this for me or has checked that already?
> 
> Cheers
> Jean 
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-dev


-- 
GPG public key B189E8C8


More information about the Lunar-dev mailing list