Opened 11 years ago
Closed 10 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 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Included in the 20140613 book.
Note:
See TracTickets
for help on using tickets.
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.