test failure, glibc make check (chroot pass)

Ken Moffat ken at kenmoffat.uklinux.net
Fri Feb 20 12:57:50 PST 2004


On Fri, 20 Feb 2004, Bob Morgan wrote:

> This is perl, v5.8.0 built for i586-linux
>
> Note above that when I execute the lfs copy of perl (5.8) from outside chroot,
> it DOES run the executable, but running a command similar to that which
> glibc configure is running to test perl for useability, perl can't find
> the Config.pm file it needs to look up the symbols it is being queried for.
> Now note I can find things manually:
>
> gnome:/mnt/lfs # ll /tools/bin/perl
> -rwxr-xr-x    1 root     root      1053848 Feb 17 01:22 /tools/bin/perl
> gnome:/mnt/lfs # ll tools/lib/per15/5.8.0/Config.pm
> -rw-r--r--    1 root     root       226117 Jan 25 21:33 tools/lib/per15/5.8.0/Config.pm
> gnome:/mnt/lfs # grep -ie apiversion tools/lib/per15/5.8.0/Config.pm
> pm_apiversion='5.005'
> xs_apiversion='5.8.0'
> =item C<pm_apiversion>
> >From F<xs_apiversion.U>:
> written for $pm_apiversion will still work for the current
> back to pm_apiversion.  This is only useful if you have a perl
> =item C<xs_apiversion>
> >From F<xs_apiversion.U>:
> directories across major versions back to xs_apiversion.
> gnome:/mnt/lfs #
>
> SO, I can manually find what the perl command cannot.  Again, this is
> from outside the chroot jail.  This is sort of pointing out to me
> that maybe perl 5.8 didn't get 100% built correctly, but I don't know
> what is missing.  And I haven't the slightest idea where @INC lives in
> perl, unless it is hardcoded in the executable or a library.  Also
> I wonder if perl somehow has an environment different from the shell
> that is launching it?
> Let's repeat some of this from inside chroot:
>

 Look about 7 lines below here for @INC, the directories are on the very
long line-

> root:/sources/glibc-build# ls -l /tools/bin/perl
> -rwxr-xr-x    1 root     root      1053848 Feb 17 01:22 /tools/bin/perl
> root:/sources/glibc-build# perl -v
>
> This is perl, v5.8.0 built for i586-linux
>
> root:/sources/glibc-build# perl -V:xs_apiversion
> Can't locate Config.pm in @INC (@INC contains: /tools/lib/perl5/5.8.0/i586-linux /tools/lib/perl5/5.8.0 /tools/lib/perl5/site_perl/5.8.0/i586-linux /tools/lib/perl5/site_perl/5.8.0 /tools/lib/perl5/site_perl .).
> BEGIN failed--compilation aborted.
> root:/sources/glibc-build# ls -l /tools/lib/per15/5.8.0/Config.pm
> -rw-r--r--    1 root     root       226117 Jan 25 21:33 /tools/lib/per15/5.8.0/Config.pm
> root:/sources/glibc-build# grep -ie apiversion /tools/lib/per15/5.8.0/Config.pm
> pm_apiversion='5.005'
> xs_apiversion='5.8.0'
> =item C<pm_apiversion>
> >From F<xs_apiversion.U>:
> written for $pm_apiversion will still work for the current
> back to pm_apiversion.  This is only useful if you have a perl
> =item C<xs_apiversion>
> >From F<xs_apiversion.U>:
> directories across major versions back to xs_apiversion.
>
> AND SO it behaves about the same from inside chroot.
> (and of course, I can't see the old host version from inside the jail)
>
> Now, when I get to the make check step in glibc near the beginning of
> the chroot build (Ch 6), and pick through the glibc configure script and the
> config.log, which are a little above my head anyhow, it eventually
> ends up saying perl=no, and like Ken said, the missing glibc test script
> mtrace doesn't get built.  Excerpts with the word perl from config.log:
>
> configure:4109: checking for perl
> configure:4127: found /usr/bin/perl
> configure:4140: result: /usr/bin/perl
> ac_cv_path_PERL=/usr/bin/perl
> PERL='no'
>
> note the symlink to the real thing here:
>
> lrwxrwxrwx    1 root     root           15 Feb 17 01:47 /usr/bin/perl -> /tools/bin/perl
> root:/sources/glibc-build# ls -l /tools/bin/perl
> -rwxr-xr-x    1 root     root      1053848 Feb 17 01:22 /tools/bin/perl
> root:/sources/glibc-build#
>
>
> What's next, drop back to the latter stages of the tools build, and
> try to rebuild perl, and if so, how to proceed?  Just re-run it and
> pay closer attention to typing, or does something have to be completely
> wiped to rebuild if not just rebuild over the problem, or what?
> Assuming I followed directions OK the first time, what would I do
> differently? (no guarantee here that I did that.  Between ch5 and ch6, I
> got GPM working and started pasting commands, but during the tools build I
> was rekeying stuff in).
>
> As an aside, this looks like something that might make a good sanity
> check of the perl tools build, since it is simple to set up, and does
> test the ability of perl to find its own config file as well as just
> to run the executable:   perl -V:xs_apiversion
> Also, I noted that the configure script in glibc actually said
> just apiversion, without the xs_ or pm_ prefixes, and don't know
> how that is supposed to play out either, again those scripts are
> a little over my head for now. Here that is:
>

 Blimey, I tought you were a perl wizard until you said that.  I really
haven't got a clue what all that stuff does :)

 I'm lost in your detail, but are you saying that perl seems to work
inside chroot, but not for the configure script ?  That doesn't make
sense.  If you're _not_ saying that, use ldd on the version in /tools,
from outside chroot, to see what it's linked to.

 In my case, I'd managed to move the files to the 5.8.0 directory, but I
was actually installing 5.8.2 so it didn't find them in @INC@ (lack of
attention to detail when putting a new version into the script).

Ken
-- 
Brighton tops UK Jedi league
http://www.theregister.co.uk/content/28/35186.html




More information about the lfs-support mailing list