bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_PROG_CC fails when target C library is missing fopen


From: Ralf Corsepius
Subject: Re: AC_PROG_CC fails when target C library is missing fopen
Date: Thu, 06 Aug 2009 07:02:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090715 Fedora/3.0-2.5.b3pre.hg.6a6386c16e98.fc11 Thunderbird/3.0b3pre

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]