Opened 9 years ago

Closed 8 years ago

#944 closed task (fixed)

Clearly define why we build GCC twice

Reported by: Andrew Bradford Owned by: Andrew Bradford
Priority: major Milestone: CLFS Embedded 1.0.0
Component: BOOK Version: CLFS Embedded GIT
Keywords: Cc:

Description

It's not described in the GCC-final section at all why we're doing this again. That can be confusing.

Change History (3)

comment:1 Changed 9 years ago by Andrew Bradford

Owner: changed from clfs-commits@… to Andrew Bradford
Status: newassigned

comment:2 Changed 8 years ago by William Harrington

I'll explain how LFS has done it in the past and why we do it in CLFS:

The first pass of binutils is to provide the tools for your target architecture that build into /tools. The first pass of gcc is static so it does not go looking for the glibc startfiles (Which don't exist, yet). Then you build glibc into /tools providing the startfiles, ld-linux.so.2, libc.so, and a bunch of other libs. Then you can build a gcc with --enable-shared so that you have a cross-compiler that creates dynamically linked executables against the glibc you built after the first pass of gcc. Binutils is only needed to be built once because you're not changing the search path at all.

In LFS, You go from linking to the host to after adjusting the toolchain linking to /tools.

In CLFS, your toolchain is setup to link against /tools from the start. That is why there is no adjusting the toolchain cross-tools or tools.

Last edited 8 years ago by William Harrington (previous) (diff)

comment:3 Changed 8 years ago by Andrew Bradford

Resolution: fixed
Status: assignedclosed

Included in the 20140613 book.

Note: See TracTickets for help on using tickets.