Gerard Beekmans wrote: >> You are arguing because of an implication that, quite honestly, I don't see.
> I'm not trying to be argumentative. I was using the term argument in a more formal manner: a coherent series of statements leading from a premise to a conclusion, not in the sense of an altercation. > To me it's just seeing a technical > explanation that feels incomplete. Some claims are made that then aren't > further explained. I'll have to admit that I don't remember all the > nuances right now either to come up with a replacement explanation on > the fly. I've sent a private email to Greg to ask for a refresh about the reasoning behind the cross-compiling > Some explanation is always better than not at all. I agree but I still don't see what is not explained. I've re-read your post from yesterday several times. Are you saying that we should explain the process of cross-compilation? To me it is reasonably obvious that if you use cross-compilation techniques then the system can't use resources from the host architecture. We don't ask that our users be programmers, but trying to explain *how* cross-compilation "removes all dependency on the host system" seems to be beyond the scope of the book. To really understand the cross-compilation process, I think you need to be a programmer who understands compiler construction. Would the following rewording be enough? The temporary libraries are cross-compiled. Because a cross-compiler cannot rely on anything from the host system, this removes any potential contamination of the target system by lessening the chance of headers or libraries from the host being incorporated into the new tools. Cross-compilation also allows for the possibility of building both 32-bit and 64-bit libraries on 64-bit capable hardware. > This'll have to be > fleshed out more. I'd like to keep this ticket open but lower priority > for now. It's not going to have a be a show-stopper but something just > doesn't feel right about leaving this the way it is. Or close it for now > if you prefer. It can always be re-opened again in the future as part of > a bigger overhaul. The priority of the ticket is not really an issue. I'd like to get it fixed if we can agree on what is needed. There are only five open tickets right now and I'll like to address all of them except the one on multi-lib before the next release. That's not soon though. The current target date is March 1. On the other hand, putting things off just creates more pressure later. This ticket shouldn't be that hard. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
