[LFS Trac] #2094: Add a new section for build results

Jim Gifford lfs at jg555.com
Sun Oct 21 12:32:05 PDT 2007

Jeremy Huntwork wrote:
> Justin R. Knierim wrote:
>> I know I am not a hardcore developer in either lfs or clfs, so my voice 
>> isn't one of much authority, but if I could throw out my opinion.  It is 
>> clear that supporting multiple arches is becoming more and more useful.  
>> CLFS is a sub project of LFS and already has working and tested 
>> implementations for so many arches, with 32bit, 64bit and multilib.  
>> These are not all useful at this time in the main LFS book.  While 
>> research is always fine, why would one do research that has already been 
>> done for possibly even years now by CLFS devs and not even drop them a 
>> message saying "how can X arch or X bit system be best implemented in 
>> LFS?"  I know Jeremy is a great guy and does good research, but in my 
>> opinion not contacting CLFS devs _is_ re-inventing the wheel.  Is it so 
>> hard to email one of us to ask for opinions or ideas?
> For now, two things:
> 1. This should hardly be a surprise, the jh branch has existed for 
> months (before that there was the x86_64 branch) and from the very 
> beginning one of its main goals was to support x86_64. The reason for 
> that was the growing realization that people want support for that and 
> perhaps other architectures in _LFS_. There has been a great deal of 
> discussion about all of the development happening there on the lfs-dev 
> list - if you were really that interested in what LFS is doing surely by 
> now you would have noticed.
I didn't have any issue for the JH branch pursuing x86_64, that's the 
next level for LFS. But when you attempt to do other architectures, that 
is when I had the issue, most people on LFS can support both x86 and 
x86_64, but when you venture to Sparc and PPC, there is not a lot of us 
out their. When you stepped into the other architectures it affects 
CLFS. We don't have the resources to support both multi-architecture LFS 
and CLFS.
> 2. We aren't re-inventing the wheel. Especially in the beginning, CLFS 
> was heavily consulted. We are simply porting the general LFS build 
> method to other architectures by providing necessary fixes, some 
> originating from CLFS, some from DIY, and some are original.
We were??  I sure wasn't and neither was Ryan. Your trying to design the 
chroot method of CLFS into LFS for other architectures, now your 
stepping into an area I would consider us the experts in. So why go 
their without cooperation with CLFS.
> In any case, after going through CLFS build methods, there's a number of 
> things there that seem unnecessary. Alexander already mentioned the 
> 'file' issue. Another: why does binutils have a --disable-multilib 
> switch? Also, why patch things heavily to use 64-bit locations when 
> building 64-bit only when you can just create symlinks, e.g., lib64 -> lib?
> --
> JH
Now here's the big question and my opinion - so you may get offended, so 
I apologize in advance for that.

You seem to come and go when you want. You start something then leave 
and them come back and start something. If you leave again are their 
resources in place that can do this work for the other architectures 
besides x86_64? It seems like you created a branch to play around with, 
and now your trying to get it in the mainline. To quote yourself your 
not a "hardcore developer", but your trying to influence the direction 
of LFS to meet your needs.

More information about the lfs-dev mailing list