Gerard Beekmans wrote: >>> What more do we need to add? Or can we just close the ticket? >>> I think it was addressed in the updates Matt made about four months >> ago >>> and about 2 months after ticket 2412 was opened. >> I'm happy to close that ticket off, I don't think it needs any more >> explanation but am open to suggestions. I'll close the ticket on >> Monday if >> we've had no further comments, if that's OK? > > > I think it can use a bit more refining. I'm writing this email without > relying on existing knowledge. If I read the page as-is without having any > additional knowledge in the area of cross-compiling, it doesn't quite make > sense yet. > > There are the three bullets that explain three key technical points. > Comments on the first two: > > 1) Slightly adjusting the name of the working platform, by changing the > "vendor" field target triplet by way of the LFS_TGT variable, ensures that > the first build of Binutils and GCC produces a compatible cross-linker and > cross-compiler. Instead of producing binaries for another architecture, the > cross-linker and cross-compiler will produce binaries compatible with the > current hardware. > > 2) The temporary libraries are cross-compiled. This removes all dependency > on the host system, lessens the chance of headers or libraries from the host > corrupting the new tools and allows for the possibility of building both > 32-bit and 64-bit libraries on 64-bit capable hardware. > > > We should add why cross-compiling removes all dependency on the host system. > The statement as-is implies that regular compiling does not yield the same > result. That has to be explained rather than just taking the statement at > face value. Providing an example would go a long way to illustrate the > problem.
I'm not sure that we really have to use cross-compiling techniques in LFS, but it is one technique of several that would work. I don't really recall any issues form the old technique except that it was limited to x86->x86. Ryan Oliver and Greg Schafer wanted to create a method that was consistent for multiple architectures that was basically any->any. For LFS, I don't think it was technically required, but changing to make is consistent with other projects such as CLFS is a reasonable goal. > An example of how the host can corrupt the temporary libraries when you > don't cross-compile would be very educational as well. It helps in proving > that cross-compiling really is recommended. I don't think the above is applicable. > This whole portion of the build process plays a very important role. Right > now that one page doesn't explain the many issues that cross-compiling > overcomes. One of the questions that may come up is why we didn't > cross-compile in older versions of the book. We obviously encountered > problems and changed the process in the book. But the rationale behind that > is still missing and not clearly explained. I don't recall explicit problems, but I didn't run the ICA analyses. I've emailed Greg to see if he can shed any light on this topic. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
