This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sat, 10 Sep 2005, Dan Kegel wrote: > Robert P. J. Day wrote: > > On Sat, 10 Sep 2005, Dan Kegel wrote: > > > > > > > Robert P. J. Day wrote: > > > > > > > credit where credit is due, it was a private e-mail from michael > > > > that pointed me at the appropriate architecture makefile as the > > > > source for some unwanted compiler options when trying to run the > > > > *native* compiler. > > > > > > How about posting a patch to fix the kernel sources, now that you've > > > found the problem? > > > > > > but, again, is this really the direction you want to take? > > Think about it... are toolchains the only thing I build? having just spent 13 hours driving across 5 states, i'm in the mood to play devil's advocate. from the perspective of crosstool, i don't think it matters in the *slightest* what else you want to build. let me explain. the primary and overriding purpose of crosstool is to build a cross-compile toolchain, and that's it, nothing more. the goal should be to create the most reliable tool there is. if (and i stress *if*) crosstool were to do anything *extra* as a bonus, that's fine as long as that bonus doesn't interfere in any way with crosstool's primary function. now, i think we all agree that, when it comes to reliability, using sanitized headers beats using a kernel source tree every which way to sunday in terms of reliability. so if we're talking about just building a toolchain *and nothing more*, using the sanitized headers is a no-brainer over the kernel source. that's not even a point of debate anymore. your position seems to be that you also might like to cross-compile the kernel as well, as a kind of freebie bonus. i would contend that's fine as long as this didn't affect the reliability of building the toolchain. clearly, though, that's not the case. trying to use the kernel source tree can obviously have an effect on building the toolchain itself. i contend this is a *very* bad thing. the fact that a failure in the kernel configuration can cause the build of the toolchain to fail is, in my opinion, unacceptable. those two are entirely independent operations and linking them in this way is adding what is essentially a totally bogus dependency to the toolchain creation. let me suggest an alternative. if you're dead set on being able to compile the kernel source while building a toolchain, make those two entirely independent operations. let the toolchain build rely solely on the sanitized headers -- this makes the toolchain build as simple and reliable as possible. *then*, if the toolchain builds, the build script can test both of the variables LINUX_DIR and KERNELCONFIG and, if they're both set to meaningful values, the second step can be to cross-compile the kernel. this would appear to solve all of the problems, no? (that is, LINUX_DIR is not used in any way in the toolchain creation -- sanitized headers are required.) and, yes, i'm tired. and, yes, adding kernel patches to get around this is a bad idea. rday ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |