{B,C}LFS State of Things (was Re: SVN-20070706: ...)

[Joe Ciccone]

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.