>On Sun, 26 Jun 2011 13:13:18 -0500
>Bruce Dubbs <[email protected]> wrote:
> Andrew Benton wrote:
> > The current patch tests if ${prefix}/lib/libc.so.6 exists and then
> > it gets the version of libc from /lib/libc.so.6, the one installed
> > on the host...
> I'm not sure why the change was made in 2008, but it has worked fine
> since then. The patch is only used in Chapter 5. What problem are
> we solving by making a change?
>
> -- Bruce
The problem with the current patch, perl-5.{whatever}-libc-1.patch,
is that it wants to check the version of libc installed in $prefix, as
opposed to checking the version of libc in /lib, which perl does by
default.
But it does not do that.
-if test -L /lib/libc.so.6; then
+if test -L ${prefix}/lib/libc.so.6; then # 1
libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'` # 2
- libc=/lib/$libc
+ libc=${prefix}/lib/$libc # 3
fi
In 1, it checks to see if there is a libc in $prefix. Then, in 2 it
checks the version of /lib/libc (!), and uses that knowledge in 3 to
build a path to $prefix libc.
Now, if the libcs are of the same version, no bad things will happen.
But, if they are different, $libc will be assigned a path to a file
which does not exist.
The correction fixes this, so that perl checks the version of $prefix
libc.
In the normal LFS build process, this bug should be triggered when the
new system is upgraded to version of glibc different from the host
version.
I just checked and the patch that I use is the corrected one. It has a
timestamp of 2009-10-01 but is probably dating to summer of 2009. I
(incrementally) upgraded my system glibc from 2.3.6 to 2.9 during that
summer and probably hit the bug (I subscribed to LFS maillists during
November).
BTW, I noticed the bug accidentally, while checking the mail before
going to bed.
--
-Aleksandar Kuktin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
