>> Now I need to build binutils and make sure that it sees the correct >> toolchain - > > You have it backwards. Binutils, then gcc, then glibc. Not glibc, > then binutils. > > What exactly are you going after. It's an experiment. I wondered whether one could build the four core packages in the order given in chapter 6, but not install them (i.e. store them as package archives) until they're all built (using LFS as the platform for this). These core packages could then be updated without the possibility of LFS becoming unstable if there were to be a major version change in one of these packages. i.e. one wouldn't have to build from scratch.
That's why it's: 1) api-headers 2) glibc 3) binutils 4) gcc So glibc will be compiled using the headers from 1) binutils will be compiled with the headers and the libraries from 2) gcc will be compiled with what's available from 1), 2) and 3) plus anything else it needs from the existing host (LFS in this case). I don't know, may be this is a daft thing to try but it's a good way for me to understand how gcc gets all the locations of the files it needs. In the above case, gcc needs to use all the libraries created by glibc, when it compiles binutils. I haven't achieved that yet and may be it's not possible. By using the specs file I can get gcc to use the headers from 1), the dynamic linker from 2) and some of the other files from 2) but not all of them. For e.g. gcc picks up libc.so.6 from /lib64 on LFS and not from the glibc archive. I don't yet know how to control that or indeed if I can. I would guess I need control of gcc's SEARCH _DIRs. jb. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
