The new build method is in...

Ryan Oliver ryan.oliver at performiq.com.au
Mon Dec 15 22:24:17 PST 2008


Jeremy Huntwork wrote:
> ...Mostly.
>
> With revision 8755, the new build method from DIY is in place with the 
> exception of support for multilib. (More on that in a second.)
>
> I tried to make as many textual changes as I could to keep the accuracy 
> of the book on a high level, but I'm sure I missed some things that 
> referenced the old build methods. I would appreciate it if you all could 
> take a second to read through Chapters 4 & 5 particularly to help spot 
> discrepancies. Until the book renders tonight/tomorrow, there is a 
> rendered version here:
>
> http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk
>
> There is no technical hindrance to bringing in multilib, the changes are 
> minimal. The effect is not so minimal. I would like to know people's 
> thoughts on how to deal with multilib in LFS. Specifically, how do we 
> handle for x86, where multilib is not an option? Do we just have a note 
> that says 'for 64-bit architectures only'? If so, how do we handle this 
> in jhalfs?
>
> Another side note, jhalfs can't currently handle the new build method 
> becuase it hard-codes the build user's .bashrc file. A slight tweak in 
> jhalfs to match what is now in Chapter 4 should take care of it. CCing 
> George Boudreau so he can fix it up when he as a second.
>
> Thanks!
>
> --
> JH
>   
Couple of minor things

1: Chapter 6.15 - If you aren't bootstrapping the compiler, you wont be 
using the newly created binutils to build your new gcc. Either bootstrap 
or add CC="gcc -B/usr/bin" to override GCC_EXEC_PREFIX.

2: Just to bring up again the use of -B/foo/lib to set startfile search 
paths. We've been through this before (nearly three years ago)

http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg05545.html

Nothing has changed since

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353#c7

LFS isn't affected by the "-specs handling bug" as we do not pass 
-specs=/some/specfile on the gcc command line (we regenerate one in the 
standard place in ch 6.10),
so we can edit the specs to our hearts content, therefore dont need to 
hack gcc.c itself.

STARTFILE_PREFIX_SPEC is unpalatable to some for whatever reason, yet it 
still exists in the gcc code to provide the only mechanism to override 
the search path used for finding startfiles when cross-compiling (see 
gcc.c line 6332, read the code and comments)

You should however be able to use/override 
STANDARD_STARTFILE_PREFIX_1=/tools/lib (continue nullifying 
STANDARD_STARTFILE_PREFIX_2) instead if you are doing a native build 
(which you are) and find STARTFILE_PREFIX_SPEC objectionable (for 
whatever reason).

Note: startfile_prefix_spec and standard_startfile_prefix* ARE expanded 
by the multilib spec out of the box.

There is no need for replacing things removed by gcc devs from gcc.c 
circa 1999, use what is provided for its specified purpose.

Just some thoughts

Regards
[R]



More information about the lfs-dev mailing list