Proposal: temporary Perls in multilib

Ken Moffat ken at linuxfromscratch.org
Thu Nov 10 14:13:22 PST 2005


  I was going to do this before we had our own list, but I got 
side-tracked with other issues, although I did slim down the final 
system to one perl.  Since we have a list, it seems better to raise this 
before I do it:

  We build the temporary perl(s) to support the testsuites of glibc and 
coreutils.  In multilib, we build perl for each supported architecture 
(that's three times on mips64, twice on the others).  The perl that we 
execute in the tests is the last one we built (64-bit), but because the 
instructions to sed hints/linux.sh don't work (accidental omissions of 
other stuff), this looks at the "regular" perl modules in /tools/lib to 
find necessary modules.

  I stumbled on this when I tried only building a 64-bit temporary perl 
in x86_64, and it failed to find the necessary modules.  The current 
method only works because everything we need is pulled in as source 
code, so the (32-bit) source works, but it isn't pretty and it's 
unnecessary.

  What I intend to do is build perl once in the multilib temporary tools, 
as 32-bit.  The advantages, as I see them, are that the libc-1 patch 
from vanilla LFS does all that we need:
  32-bit perl in /tools/lib/perl5/
  no extra work to put the libraries in lib64 or lib32
  no extra work to correct the output from 'perl -V'.
(compare the perl in the final system for the last two points)

  The reason for building 32-bit is my desire to build perl appropriately 
for /tools/lib (and so avoid extra patching plus -Dlibpth).  Therefore, 
if we ever get lib32+lib as an option, the corresponding perl would be 
built 64-bit.

  Tested last month on x86_64.

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


More information about the cross-lfs mailing list