From glibc-2.2.x to glibc-2.3.x
gschafer at zip.com.au
Wed Oct 30 13:38:08 PST 2002
On Wed, Oct 30, 2002 at 09:53:35AM -0700, Gerard Beekmans wrote:
> <snip everything>
> I'm finding myself in between a rock and a very hard place. The "export them
> symbols" patch is the easiest and cleanest solution. I agree with that camp.
> But, not having a pristine Glibc isn't a great thing either and I would like
> to avoid that. It doesn't matter much to me wether or not other distributions
> use that patch. I know the reasons they use it and I can appreciate it. But I
> also try to aim at having a system using packages as the developers intended
> it. So I agree with the "LD_LIBRARY_PATH hack" camp too.
Gerard, you should have been a politician :) Very diplomatic!
> But I don't particularly like the idea of having to do chapter 6 (partially)
> twice. Even if you don't remove the glibc-* directories after building it,
> simply reverse the patch (patch -R) and re-issue 'make && make install' it
> shouldn't take all that long (well that's the theory. It doens't always work
> that way) but after reversing the patch we'd have a number of static programs
> installed already. Would they still work or would we need to reinstall those
> packages too.
> If we're lucky and all the static programs installed in chapter 6 will still
> work after we reinstall Glibc without the patch, we might have a viable
> solution that would make both camps happy: 1) easiest installation 2)
> unpatched Glibc (eventually)
Yes, leaving the glibc sources and build dir lying around does work. That is
exactly what I was doing when testing. The trick is deciding exactly when to
reverse the patch and re-issue 'make && make install'. The safest time would
be at the end of Ch 6. The main packages affected are bash, fileutils and tar.
Tar is right near the end. So unless the build order is changed...
Of course this solution would blow the space requirements numbers out of the
water due to leaving glibc sources and build dirs lying around for the entirety
of Ch 6.
I still firmly believe the "export them symbols" patch is the way to go. We
have already established the technicalities associated with it. Now it is
just a matter of overcoming the mental obstacle of not using a pristine source.
It is worth keeping in mind that the patch in question entered the glibc cvs
just a few weeks before release. It could have quite easily been released
without it. I wouldn't be at all surprised if there are other internal symbols
which haven't yet been hidden away.
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