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
