Re: [gentoo-dev] Possible Change in Glibc Versioning

[Travis Tilley]

On Friday 23 April 2004 04:17 am, Ned Ludd wrote:
> On Thu, 2004-04-22 at 04:18, Kumba wrote:
> > I was made aware in #pax of a shift in glibc's versioning mechanism.
> > Most by now have noticed there hasn't been a glibc-2.3.3 package
> > released by GNU.  I don't think there will be one.  Skimming some
> > threads on the libc-hacker mailing list, the general attitude seems to
> > be letting the individual distributions take snapshots and decide what
> > is stable and what isn't.

well then, I say we do just that. lets start by taking a new snapshot and 
adding it to the tree for testing. the last snapshot seems to have very 
strange problems on amd64 that are really only triggered by gtk+-2.4 with any 
regularity. I would also like very much to start doing more serious 
preparation for moving over to gcc 3.4.0 some months down the line, and our 
current snapshot (and latest stable glibc on amd64) seem to not be very gcc 
3.4 friendly (SSP in glibc 2.3.2-r9 breaks and destroys your entire install, 
as everything will have unresolved __guard symbols, more later).

also, it seems there is some strangeness in bits/string2.h, to quote from bug 
#48797:
"This is a bug in bits/string2.h in glibc: the macro definition of strpbrk() 
expands to a ?: expression which can have a type of (char *) or NULL, which 
in Linux is of type (void *). This is a bug as one cannot use (void *) 
everywhere (char *) is allowable, in this instance on the LHS of the - 
operator.
[...]
It will show up as bugs compiling packages with gcc 3.4, e.g. bug 48798."

also, due to some apps (on amd64, with glibc 2.3.3*) dying consistantly in 
pthread_getconcurrency (), and the fact that our arch doesn't even support 
the 2.4 kernel, i would like to know if we can make the Native Posix 
Threading Library a default of sorts on amd64 instead of linuxthreads. 
However, there are some problems that need to be taken care of before we 
could do this... glibc with NPTL cannot reliably compile using headers taken 
from the current kernel, linux-headers 2.6* are masked, and even if the 2.6 
headers were unmasked a large number of applications simply will not compile 
with them. i've recently fixed linux-headers 2.6.5 to compile glibc with NPTL 
on amd64, and i think it'd be a good idea to use these patches and headers 
from within the ebuild itself to compile NPTL on this arch. it's too much of 
a PITA to do it any other way, and far too unreliable... i'd also like very 
much to get NPTL working without breaking anything else.

> If the version has changed then we should probably move away from
> calling them pre releases. perhaps something like 2.3.X.0.YYMMDD ?
>
> > --Kumba

yeah... they're definately not pre-releases if there isn't going to be a 
release. :-|


to backpedal a bit: SSP. why is this forced onto all users of all archs 
regardless of whether or not they intend to use SSP? I dont really like this. 
I'd suggest a "nossp" USE flag, but at this point that isn't even possible! 
any removal of SSP from glibc will cause every single application on every 
single gentoo install to break horribly with errors about missing 
__guard@glibc. we are now dependant on it and can never move away without 
some seriously hardcore pain. also, it might be a bit more of a concern for 
embedded system users who might need to use a libc other than glibc and start 
off using non-static apps linked against glibc... but i'm not really familiar 
with embedded. there are probably many more issues here that i just havent 
realised yet, but for what reason were we pushed into this?


Travis Tilley <lv@g.o>
Gentoo/AMD64 Developer

--
gentoo-dev@g.o mailing list