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

Matthias Benkmann matthias at
Sat Oct 26 02:03:41 PDT 2002

On Sat, 26 Oct 2002 08:31:07 +1000 Greg Schafer <gschafer at>

> On Fri, Oct 25, 2002 at 08:45:06PM +0200, Matthias Benkmann wrote:
> > Have you checked for hardcoded paths? Since the /static separation was
> > introduced, the build order is *very* fragile.
> Can you give an example of breakage that might occur by changing the
> build order?

See Appendix A of the keep_chap5_and_chap6_separate hint.
> > Why do you prefer this to the LD_LIBERRY_PATH hack? It's much more
> > work and much more likely to break things because unlike the
> > LD_LIBERRY_PATH hack it not only affects the /static binaries but also
> > the chapter 6 binaries, and unlike the LD_LIBERRY_PATH hack which only
> > affects bash, tar and ls, the nsswitch affects *all* binaries.
> 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.

> 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?
> 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

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?

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 tried sniffing Coke once, but the ice cubes got stuck in my nose.

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