Cross-LFS multilib - perl

Ryan Oliver ryan.oliver at
Wed Oct 19 18:55:36 PDT 2005

On Wed, 2005-10-19 at 02:07 +0100, Ken Moffat wrote:
>   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 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.

Missing fixes in the book

>From the cross-lfs scripts
#adjust Configure and append to if not installing to */lib
if [ ! "${libdirname}" = "lib" ]; then
   # We need to adjust Configure so that it understands 
   # installstyle=lib64/perl5 and sets up directory paths accordingly
   # NOTE: may need to check how this affects vendor libs...
   if [ ! -f Configure-ORIG ]; then cp Configure Configure-ORIG ;fi
   sed "/\*lib\/perl5\*).*/{
        G }" Configure-ORIG > Configure

   # Now that installstyle can handle lib64, specify our
   # our installstyle in
   echo "installstyle=\"${libdirname}/perl5\"" >> hints/

This basically adds an installstyle for libFOO (be it
lib32/libn32/lib64) to the perl configuration and forces its use

example patch for x86_64 lib64 attached (rename it to something

Ensure installstyle="lib64/perl5" is appended to hints/ if the
patch is used.

>   These are happening because hints/ 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.

See above

>   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

Just thought I'd pipe up here... what use is there having both 32 and
64bit modules created if you are only going to be able to use either a
32 or 64bit perl?

Indeed, if you attempt to build 32bit modules down the track with a
64bit perl they wont get used (if the above fix is implemented) or will
not work (if they are installed to the same location as the 64bit ones).

Also you will pickup the wrong install locations from the 64bit perl,
pick up wrong library paths to use etc, run perl Makefile.PL on any
additional module and you'll see what I mean... 

You need to keep both perl binaries.

I have been using a binary wrapper to be able to host two versions of
perl/python/whatever you want, by renaming the perl binary to perl-32 or
perl-64 and creating a perl -> wrapper_binary symlink. The wrapper
checks an environment variable then runs the appropriate perl binary.
(NOTE: wrapper has to be a binary, not a shell wrapper, or else perl
scripts break when invoked).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: perl-5.8.7-x86_64_lib64_Configure.patch
Type: text/x-patch
Size: 978 bytes
Desc: not available
URL: <>

More information about the lfs-dev mailing list