From glibc-2.2.x to glibc-2.3.x

Greg Schafer gschafer at
Sat Oct 26 06:21:51 PDT 2002

On Sat, Oct 26, 2002 at 11:03:41AM +0200, Matthias Benkmann wrote:
> On Sat, 26 Oct 2002 08:31:07 +1000 Greg Schafer <gschafer at>
> > Lets face it, sed'ing binaries is very unpalatable. I can understand why
> > some folk will object.
> I could understand this for my original proposal which replaced "libn" and
> "nss". These are very short character sequences that could occur in
> unrelated parts of the program, even code. But this is not an issue for
> "LD_LIBRARY_PATH". I'm confident that there is no Linux program whatsoever
> anywhere in the world that contains this letter sequence by accident, not
> related to the LD_LIBRARY_PATH variable. It's just too unlikely.

Agreed. But that wasn't the point. In general, sed'ing binaries is just very
hackish and is likely to repulse some folk. But Gerard has already stated he
finds the binary sed's acceptable and it obviously will be his call that
ultimately decides the matter.

> > I still don't see why the patch posted at:-
> > 
> >
> > 
> > is not a valid solution.
> It is a valid solution, but as you say yourself
> > Sure, I can understand we end up with a glibc
> > that is "not pristine". 
> LFS has a policy of keeping patches to a minimum, usually bug-fixes only.
> And of course, patches should be as easy to understand as possible. The
> LD_LIBERRY_PATH hack and its consequences can be understood without much
> technical knowlege. The glibc source code patch (and its consequences) on
> the other hand requires insider knowledge. It raises questions. For
> instance, if exporting those symbols doesn't hurt, why have the
> maintainers decided to unexport them, thereby breaking compatibility?

Insider knowledge?

root:~# /lib/ | head -n 1
GNU C Library stable release version 2.3.1, by Roland McGrath et al.

We already have a post by the dude who wrote the bulk of glibc!

He explains the situation perfectly well, even in laymans terms! I dispute
your statement "thereby breaking compatibility". The symbols in question
are internal to glibc. The convention has always been that symbols beginning
with 2 underscores (in this case for eg: __ctype_tolower) are internal to
glibc. As has recently been proven by the Sun j2sdk, Wine, Crossover plugin
and other misc apps, anyone who uses internal glibc functions is going to get
bitten on the arse.

So the answer to your question is obvious. The maintainers have ensured that
these 6 symbols are not exported because they are not meant to be exported.
But in our case, it has the unfortunate side effect of breaking "statically
linked getpwuid() using binaries that are compiled and linked against a glibc
less than or equal to 2.2.5 when run on a glibc-2.3 system for eg: bash, ls,
tar, install, etc"    Whew, that was a mouthful :)

Roland McGrath admitted that Redhat has done something similar in their 8.0
release. (I have downloaded the SRPM and confirmed they have re-exported 3
of the 6 symbols in question). So do you think the largest Linux distro
would go out of their way to break compatibility? Of course not. This is
not a compatibility issue. It is a correctness issue.

The patch sacrifices 6 symbols worth of correctness for the sake of a smooth
LFS upgrade.

> > Anyone who does the old "double shuffle" ie: builds Ch 6 twice (like me)
> > this is the perfect solution. Apply patch on 1st run, don't apply on 2nd
> > run.
> a) LFS takes a LOOOONG time to build on many machines and many people
> don't do scripted builds, so it takes even more effort. As a consequence
> many don't do the double-chapter 6

Of course, I'm just making the point that one can achieve a pristine glibc
by building it twice.

> b) what if someone does a complete bootstrap, i.e. build *both* chapter 5
> and 6 again inside chroot. Won't he have to use the patch again, because
> the new static binaries will again require the old symbols?
> In other words, if you DON'T build chapter 6 (and only chapter 6) twice,
> will you ever get rid of the patch?

Not sure I follow you here. Once you have a glibc-2.3 based system (patched
or not) you don't need the patch from that point onwards.

> b is another one of those questions the patch raises. Can you answer it
> without testing? Can you explain this issue in layman's terms? I can't,
> despite the fact that I'm an experienced programmer. Understanding the
> glibc patch and its consequences _completely_ requires in-depth knowledge,
> well beyond anything that even a programmer needs for his daily work. 
> No matter how harmless and easy to understand ("just exports some
> additional symbols") the patch looks at first glance, it is quite arcane
> if you look underneath the surface. 

I am a shocking programmer. But I'm an experienced systems builder/integrator/
tester/tweaker/wannabe/technogeek/tryhard/propeller head. I don't claim to
understand the intricacies of ELF symbol versioning and dynamic loading. But
luckily I don't need to! Thankfully Roland McGrath does! And he has confirmed
that the proposed patch is not harmful. And I believe it represents the
smoothest upgrade path for LFS.

Above all, it is a good thing we have a number of options :)

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list