[lfs-dev] Glibc-2.16.0 [ test-installation.pl ]

Ken Moffat zarniwhoop at ntlworld.com
Wed Aug 15 08:56:06 PDT 2012

On Tue, Aug 14, 2012 at 09:40:28PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Tue, Aug 14, 2012 at 08:31:36PM -0500, Bruce Dubbs wrote:
> >>>
> >>>    When the ld.so regexp triggers on x86_64, the line contains:
> >>> ld.so-version=$(if $(abi-64-ld-soname),$(abi-64-ld-soname),ld.so.1)
> >>>
> >>>    My initial reaction when I saw that was unprintable - I still have
> >>> no idea where the $(abi-64-ld-soname) comes from.  But:
> >>
> >> I thought I mentioned that on the lists.  It's an environment variable
> >> and is incompatible with the perl script.  That's why we remove it with
> >> a sed expression.
> >>
> >   Are we at cross-purposes ?
> I don't think so.  Am I missing something?
 I read your reply as "we use a sed to remove the environment
> > All I can see, as of about 24 hours
> > ago, is a sed to ensure that the Makefile line to run
> > test-installation.pl is deleted.
> Right.  Because it doesn't work as you mention above with 
> $(abi-64-ld-soname).
> >   Anyway, I forgot to note which previous sed I'm using for the successful
> > run -
> >
> > DL=$(readelf -l /bin/sh | sed -n 's at .*interpret.*/tools\(.*\)]$@\1 at p') &&
> > sed -i "s|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=$DL -o|" \
> >          scripts/test-installation.pl &&
> > unset DL &&
> Are you running on a 64-bit or 32-bit system?  I can check it again.
 64-bit.  I suspect that 32-bit on a 32bit-only i686 might not have
an issue, and that 32-bit on a 64-bit-capable processor will have a
similar problem.
> >   I've commented the other one because it looked as if upstream have
> > fixed it :
> > #sed -i -e 's/"db1"/& \&\& $name ne "nss_test1"/' scripts/test-installation.pl &&
> > and it seems they have.
> OK.  It's been a while since I looked at 7.1 stable and this isn't in 
> the current xml, even commented out.
> I'll try to put test-installation.pl back in and test it.  I've got a 
> couple of changes to make first for gcc and perl.  The problem is that 
> it takes a long time to build and test these packages and I don't want 
> to make too many changes to svn at once.
 For the moment, please don't treat this as a priority.  I've been
distracted by other things today and am nowhere near confirming that
it is indeed a perl-5.16 problem.  If it isn't caused by perl-5.16,
then fixing the perl is not the right answer.

 OTOH, if anyone is building 32-bit and can keep the glibc source
and build directories around, testing a change to the perl script
should only take a few seconds.  Oddly, I had to run it from within
the *source* directory.  If I do blame the perl version [ plausible,
a lot of "baggage" was dropped in 5.16 ], I'll produce instructions
for changing the file and for how to run it.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list