From glibc-2.2.x to glibc-2.3.x
gschafer at zip.com.au
Fri Oct 25 15:31:07 PDT 2002
On Fri, Oct 25, 2002 at 08:45:06PM +0200, Matthias Benkmann wrote:
> I have a bad feeling about this.
> 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
> 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. Having said that, the LD_LIBERRY_PATH hack is really
quite nifty (/me awards MSB extra brownie points for thinking it up :-)
In it's current form, the hack is quite clean and I could see it as a valid
solution for LFS.
> Furthermore, don't forget that the segfault issue is a one time thing. You
> only encounter it when you build a glibc-2.3 system on a glibc-2.2 system.
> If your host already has glibc-2.3, you don't need to do anything.
> Your solution would require a lot of changes spread out over the whole of
> the LFS book, thereby affecting everyone, even the people who don't have
> issues because their host runs glibc-2.3 already.
> The LD_LIBERRY_PATH hack on the other hand is a simple set of commands
> that can be put into chapter 5 like this:
> If your host system runs glibc-2.2, then issue the following commands. If
> your host runs glibc-2.3 or later, then skip them:
> [insert LD_LIBERRY_PATH hack]
I still don't see why the patch posted at:-
is not a valid solution. Sure, I can understand we end up with a glibc that
is "not pristine". But what is the patch actually doing? It is simply
enabling a few symbols to be exported which are not really meant to be.
Glibc has been exporting unnecessary symbols for years, so I don't really
see why it is such a big deal. No hacks, no changing build order, just
hassle free LFS as per normal.
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.
So in summary, the patch mentioned above suits my purposes, but I don't have
any objections if LFS adopts the LD_LIBERRY_PATH hack.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev