Re: AC_PROG_CC fails when target C library is missing fopen

[Ralf Wildenhues]

Hello,

* Ralf Corsepius wrote on Thu, Aug 06, 2009 at 07:02:25AM CEST:
> On 08/05/2009 07:56 PM, Adam Sampson wrote:
> >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.

> 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.

I don't see in this discussion where the main argument to switch to
using fopen is addressed:
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/6656>
IOW, how do you prevent AC_COMPUTE_INT and friends from getting you
wrong answers on your system (if you happen to have a simulator around)?

I wouldn't want to revert the fopen change unless we also don't regress
on the other question?

I don't quite understand Paolo's suggested patch yet, but if you require
that cross compilation be enabled you need to pass both --host and
--build.

Thanks,
Ralf