Jeremy Huntwork wrote: > On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: > >> LFS could be made to accommodate x86_64 (multilib) with very few changes >> and a bunch of new pages. Where multilib gets tricky is where lfs stops >> and blfs begins. With the introduction of pkg-config and all those fun >> *-config programs and hard coded library paths. >> > > And non-multilib is even fewer changes, and would be much easier for > BLFS to accomodate. I suppose the only concern is compliance with > standards and/or user expectations. I'm working on getting a LFS-style > native build done on x86_64 with as few changes as possible. I'll let > you know how it goes. > There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them.
You can have /lib64/ld-linux-x86_64.so.2 (symlink to /lib), /lib/ld-linux.so.2 (32bit), and /lib/ld-linux-x86_64.so.2 (64bit). Your 64bit libs in /lib. and your 32bit libs in /lib32 or some weird place lib /opt/emul_32/lib. A hint about using /opt/emul_32/lib for the specific purpose of running wine could definitely be written up. That would be useful for clfs too. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
