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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
