On Sun, Jul 01, 2012 at 11:21:44AM -0700, Bryan Kadzban wrote:
> Fun fun fun.  :-)
> 
> Andrew Benton wrote:
> > test-installation.pl failed with an error:
> > 
> > root:/sources/glibc-2.16.0# CC="gcc" /usr/bin/perl 
> > scripts/test-installation.pl /sources/glibc-build/
> > Unmatched ( in regex; marked by <-- HERE in m/$( <-- HERE if 
> > $(abi-64-ld-soname),$(abi-64-ld-soname),ld/ at scripts/test-installation.pl 
> > line 172, <LDD> line 1.
> 
> Is this an issue with the output of ldd?
>  If you can find the ldd that
> this glibc built (preferably not the one in the chapter5 /tools/bin),
> what happens if you run it on any of the /tmp/tst-prg* files?

 No, the built but not yet installed version works fine:
root in chroot /building# glibc-build/elf/ldd /tmp/test-prg23425
        linux-vdso.so.1 (0x00007fff77dff000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f057033f000)
 through to
        libnss_compat.so.2 => /lib64/libnss_compat.so.2 (0x00007f056d958000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0570542000)

> Because the test-installation.pl script simply builds a tiny C program
> with "all" the glibc libraries, and runs ldd on it.  Also it run sthis
> on the contents of soversions.mk:
> 
> if (/^ld\.so/) {
>   ($ld_so_name, $ld_so_version)= /=(.*)\.so\.(.*)$/;
> }
> 
> so it might be useful to ensure the file's contents still work with that
> regexp, not extracting something silly that would cause the later syntax
> error.
> 
 Bryan, you were perspicacious.  I've just spent a few hours
re-energising my limited perl knowledge.  First, to try to
instrument test-installation.pl, then to understand what is
happening.

 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:

 That gets split:
ld_so_name now set to $(if $(abi-64-ld-soname),$(abi-64-ld-soname),ld
ld_so_version now set to 1)

 A couple of =~ s/foo/bar/  later and I have:

ld_so_name now set to  $(abi-64-ld-soname),$(abi-64-ld-soname),ld
ld_so_version now set to 1
Your new glibc installation seems to be ok.

[ can I say QED ?  Perhaps best not to :) ]

 The loop with context from line 115 now reads:
  } else {
    if (/^ld\.so/) {
      ($ld_so_name, $ld_so_version)= /=(.*)\.so\.(.*)$/;
      $ld_so_name =~ s/^\$\(if//;
      $ld_so_version =~ s/\)$//;
    }
  }

 I *assume* that those "seds" won't trigger on non-multi-whatever
platforms (multi-ABI ?), but nowadays I only build on x86_64.

 So, my next step will be to see I can find a way of adding both
those lines in a sed.  But not tonight, I'm supposed to be spraying
some paint before I go to bed :)

 After that, I'll try to fix my build so that I can install glibc,
then stop and tar it all up - I'm guessing this is a perl-5.16
issue [ nobody apart from LFS seems to have noticed anything amiss ]
so I'll see if I can revert to perl-5.14 with everything else as in
last night's svn.  Hopefully, that will successfully run
test-installation.pl, and also my modified version. [sigh/]

ĸen

-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to