On Tue, Oct 04, 2005 at 08:40:59AM -0700, Peter Naulls wrote: > On the contrary, autoconf makes many things consistent and predictable > when cross compiling, and improvements to autoconf and other tools have > made the possibility of cross compiling much more likely for a given > package. You're more likely to have a problem with a package that > doesn't use it. > > However, the setup for Debian packages isn't always ideal for cross > building even though Mozilla certainly does.
Yeah having full support for cross compiling would be nice, but then again the current buildd system at least ensures it really does build on the architecture itself. Cross compiling also can give slightly different results than a native compile. For example if you have something like this: #define SPEED 1000 #define REDUCEDSPEED SPEED*0.1 On a native compile, it precalculates REDUCEDSPEED as 100 in any place that needs it and inserts it at compile time. Doing a cross compile, it seems gcc doesn't assume it knows how the architecture does floating point calculations and rounding and such, so it inserts the actual floating point call instead and the calculation is done at runtime. Had the code said SPEED/10 instead, it would have done the interget calculation at compile time either way since it knows how integers work on all systems. This means the resulting binary may run slightly slower if cross compiled than if native compiled, while in the case of kernel code where floating point is a no no, you end up with code that can't be cross compiled and used sincce you can't load the module into the kernel due to the floating point calls (and lack of floating point hardware on some architectures that emulate it when user space needs it). Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
