[Top][All Lists]

[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 Wildenhues
Subject: Re: AC_PROG_CC fails when target C library is missing fopen
Date: Tue, 11 Aug 2009 00:11:41 +0200
User-agent: Mutt/1.5.20 (2009-06-15)


* 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:
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


reply via email to

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