Cross-LFS multilib - perl

Ken Moffat ken at linuxfromscratch.org
Tue Oct 18 18:07:17 PDT 2005


  Hi,

it appears to me that the perl installations in a multilib build are 
broken.  First, in the temporary tools we end up with a /tools/bin/perl 
which thinks it is a 32-bit program because it uses the Config.pm from 
the 32-bit install in /tools/lib (spotted this when I tried doing 
without the 32-bit perl as an experiment).

  In the final system, perl knows it is 64-bit, but the libraries have 
again been installed in /usr/lib/perl5 over the top of the 32-bit libs.

  These are happening because hints/linux.sh doesn't have anything to 
match what we are trying to sed to lib64.  Possibly, there was an 
earlier patch that has fallen by the wayside.

  Not quite sure of the way to handle this:  For the final system, I'm 
trying a patch from fedora which puts all library stuff into 
/usr/lib64/perl5/ where it can co-exist with the 32-bit libraries.  So 
far so good, but perl -V shows

  ld='gcc -m64', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib

  which still don't seem totally appropriate.  Hmm, maybe I should have 
looked at the specfile before trying to build this - and I need to grok 
perl's Porting/Glossary to see why privlib, sitelib, vendorlib are set 
to /usr/lib/perl5/wherever on fedora multiarch builds.  Oh well, that 
can wait until after I've had some sleep.

  For the temporary tools, I'm guessing we could just build a 32-bit perl 
(assuming any 64-bit testsuites will NOT produce perl modules).

  Views ?  Refutations ?

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


More information about the lfs-dev mailing list