On Thu, Jun 12, 2008 at 04:50:31PM +0100, David Woodhouse wrote: > On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote: > > Rob Landley wrote: > > > However, having one or more full-time engineers devoted to debugging > > > cross-compile issues is quite a high price to pay too. Moore's law really > > > doesn't help that one. > > > > > > I'm not saying either solution is perfect, I'm just saying the "build under > > > emulation" approach is a viable alternative that gets more attractive as time > > > passes, both because of ongoing development on emulators and because of > > > Moore's law on the hardware. > > > > I agree with much that you have said, Rob, and I understand the argument > > for getting the most gain from the least resources, but I have a philosophical > > problem with working around the cross-compilation problems instead of fixing > > them in the upstream packages (or in the autoconf system itself). > > > > Once someone fixes the cross-compilation issues for a package, they usually > > stay fixed, if the fixes are mainlined. > > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do > the wrong thing, and people will often introduce new problems. > > If we just made people write portable code and proper Makefiles, it > would be less of an issue :) > The other issue is that people that are working in this space tend to do very little beyond solving their immediate troubles. Since perl was mentioned, it also makes a good example. Embedded distros have been cross-compiling perl for pretty much the last decade, yet even today people are having the exact same issues and acting as this is some sort of surprise that needs to be worked arond, rather than treating it as a solved problem. If you opt to cross-compile, having to deal with those sorts of things is the price you pay. Holding the kernel hostage to this kind of brain-damage is simply beyond ridiculous. There are a lot of things outside of the kernel that have a dependency on perl too, how much time do people want to spend trying to fix the build system to match their environment before they realize their environment needs to scale to match the build environment that everyone else is already using? Building under qemu in a "native" environment is one way to work around this problem, and a lot of companies have opted for that approach rather than trying to fix the problematic packages. If you aren't building natively, your options are effectively limited by convention. You can either try to fix the packages in question, convince the package developers to rip out the parts that cause trouble for your environment, fix your own build environment to meet the needs of the packages, or whine about it on a mailing list. Empirically we already know which one of those options is going to win out. ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
