Tobias Gasser wrote: > Nathan Coulson schrieb: > >> I have been experimenting with a multilib LFS System (where /lib, >> /usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used >> for 32bit). I wanted something as close to LFS as possible, >> primarily 64bit, but just enough 32bit so if I wanted to compile >> something 32bit, I could. > > > i myself like this approach with lib + lib32. > > having a look at http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64 > the standards use /lib + /lib64 for i86_64 systems. but IA64 has only > /lib with everything 64 bit. > > the standard was finished in 2004 where most i86-64 systems had full > 32 but only partial 64bit support. > > looking at nathans approach to have full 64bit with just a few 32bit > libs arroud for compatibility issues, his proposal is very reasonable > for me. i guess with his lib+lib32 even most BLFS scripts can be > used as they are, just very few will need special handling. > > for me a multilib system does not mean everything with both flavours, > nathans description seem to be the way i'd like it. > > if your intention is to build a really full blown multilib system, > fsh compliance will be fine for me too. but having a 64bit system > with some 32bit libs i vote for nathans way of doing it.
I keep repeating myself on this. But: the FHS is only *part* of the problem. The other part is that the standard linker for 64-bit binaries on x86 is */lib64/ld-linux-x86-64.so.2*, *not* something in /lib. And the standard linker for 32-bit binaries is (as it has *always* been) */lib/ld-linux.so.2*, *not* something in /lib32. If you build a system some other way, great -- but you will *never* be able to run binaries compiled by someone else. This is much less of a problem with LFS, but it is still a partial problem: I'd like someone to show me how they recompiled Rune, or Descent 3, or Quake 4, to change these programs' dynamic linker to be in /lib32. :-P Glibc even goes to some lengths to put this linker in the right place; why would you want to try to move it? (Unless you plan to put a 64-bit linker in /lib64, then a 32-bit linker in /lib, alongside a bunch of other 64-bit libraries. That seems really crazy to me...) > even most BLFS scripts should run fine out of the box with this > aproach, where as with all in lib64 i guess most scripts will have to > be updated. I don't know what you mean by "BLFS scripts", but if you mean the bootscripts, everything actually works fine. If you meant something else, what was it? > udev: the tools like ata_id, cdrom_id must be placed in /lib64/udev > as there 64bit. but the /lib/udev/rules.d must stay in /lib as these > files are NOT architecture dependent. Please, please, NO! :-) /lib64/udev is a broken setup. Yes, the tools are 64-bit -- but they aren't libraries. The libraries they use are in /lib64, but the /lib/udev directory is part of the udev ABI; change it around at your peril. See the end of http://marc.info/?l=linux-hotplug&m=121671344123866&w=2 for instance. And then try to get Kay to change that. Good luck. :-P > perl: most will be in /lib/perl as they are architecture independent > (.pm, .pod, .pl). but some libraries (.a, .so) must be moved over to > /lib64/bin. No, not /lib64/bin -- /usr/lib64/perl5/xxxx. But I'm just using a 64-bit-only perl. Works so far. *cross fingers* (Yes, it is in /usr/lib64/perl5, since it installs libraries. Since it doesn't have a good way to move binaries around, they're sitting wherever it dumped them by default. But then, I went through the full Perl "./Configure" interactively...)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
