On 08/05/2009 07:56 PM, Adam Sampson wrote:
Hi,
I've upgraded to autoconf 2.64 recently, and it works nicely -- except
in one slightly odd configuration.
One of the projects I work on (KRoC, an occam compiler and runtime) can
be cross-compiled for the AVR series of microcontrollers. This used to
work, but now this happens:
checking for avr-gcc... avr-gcc
checking for C compiler default output file name...
configure: error: in `/home/ats/src/kroc-svn/obj-avr/modules/inmoslibs/libsrc':
configure: error: C compiler cannot create executables
See `config.log' for more details.
What's going on? Well, the AC_PROG_CC test now tries to compile a little
program that uses fopen -- but the AVR-GCC toolchain uses avr-libc,
which doesn't provide fopen. (Which might seem silly -- and is certainly
non-standards-compliant -- but kind of makes sense when your typical
target device is a microcontroller with 8K of flash, and nothing even
vaguely resembling a filesystem.) In 2.63 and earlier, the program it
compiled just did "return 0;", so it was quite happy with avr-libc.
We are facing a similar regression with autoconf-2.64 and rtems.
The fopen check pulls in a chain of file-io related symbols, causing all
AC_PROG_CC to fail, because rtems has them outside of libc.
Any suggestions? I suppose one option would be to try to persuade the
avr-libc maintainers to add a dummy fopen() implementation that always
returns NULL...
That's what we (rtems) currently are doing.
Unfortunately, this approach opens a can of worms, because when doing
so, AC_CHECK_FUNC etc. will return bogus results (false positives) when
checking for presence of fopen and other file-io related functions (e.g.
while using autoconf to build the library providing fopen etc).
IMO, it would be best to revert the change in autoconf.
Ralf
