a bug in the perl patch

Aleksandar Kuktin akuktin at gmail.com
Sun Jun 26 17:05:07 PDT 2011


>On Sun, 26 Jun 2011 13:13:18 -0500
>Bruce Dubbs <bruce.dubbs at gmail.com> 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



More information about the lfs-dev mailing list