[uClinux-dev] asterisk with uClinux error

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Thu May 6 15:35:20 EDT 2010


On Thu, May 06, 2010 at 06:00:13PM +0100, Jamie Lokier wrote:
> The above error should not occur if ./configure is called correctly
> for cross-compilation.  config.log will explain what it's doing before
> it complains.

For a few autoconf tests it does and there is no way to avoid it.
In the case of gcc 4.3 it is a well known bug that somehow none of the
developers have ever cared to go and fix.

> > autoconf is simply evil when you are trying to cross compile.  A terrible
> > horrible mess.
> 
> Yes, but on the other hand, it often works better than the
> non-autoconf source tarballs in my experience :-)

Well so far the best things I have dealt with use Kbuild.  So busybox,
linux kernel, uclibc, etc.  No problems with cross compiling ever.

> Needing to execute something is poor form, but doesn't seem to happen
> in most packages.

True.  But it does in some.

> Dependency on Glibc, or sometimes even specific version of Glibc, or
> sometimes kernel headers that are only prevent in kernel version X, or
> x86 arch only, whatever the author had on their system at release
> time, now that's really horrible stuff I've seen in non-autoconf
> packages for those needing to cross-compile.

That can happen in autoconf too.  Autoconf is only as smart as the person
writing the tests and the code to deal with the test results.

> (Rob Landley's answer is to give up cross-compiling, and do everything
> inside qemu for the target arch.)

Yep.  And I agree entirely with him, and in fact do that for most things.
The only things we cross compile here are the things for uclinux on the
coldfire.  All the powerpc code is natively compiled, although we really
would like to get a hold of a much faster powerpc machine for compiling
(currently considering a dual core power6 blade from IBM).  Compiling on
a freescale development board is a bit slow, yet still preferably to
the nightmares of cross compiling things in general.

-- 
Len Sorensen



More information about the uClinux-dev mailing list