[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 Corsepius |
Subject: |
Re: AC_PROG_CC fails when target C library is missing fopen |
Date: |
Wed, 19 Aug 2009 14:30:11 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 |
On 08/12/2009 06:51 PM, Ralf Corsepius wrote:
On 08/12/2009 02:09 PM, Eric Blake wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Paolo Bonzini on 8/10/2009 4:27 PM:
On 08/11/2009 12:11 AM, Ralf Wildenhues wrote:
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)?
In my patch I use an empty source code file to determine the default
file name. Then I use one with fopen to determine if the user is
cross-compiling; this would fail for RTEMS so that the preprocessor-only
AC_COMPUTE_INT is used.
If we get feedback from both RTEMS
I am observing what I would call "partial success".
Using atoi definitely is much better than fopen for RTEMS
(Thanks Paolo!).
However, with this check applied, I am now observing a similar problem
with autoconf's "check for cross-compilation", when using a toolchain
with RTEMS function stubs removed (The official rtems toolchains have
these stubs)
Example:
# cat configure.ac
AC_PREQ([2.64])
AC_INIT([cccheck],[0.2])
AM_INIT_AUTOMAKE([foreign 1.11 dist-bzip2])
AC_PROG_CC
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
# ./configure --host=i386-rtems4.10
The resulting config.log shows this:
...
configure:2729: checking whether we are cross compiling
configure:2737: i386-rtems4.10-gcc -o conftest conftest.c >&5
/opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-findfp.o):
In function `__sfmoreglue':
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/findfp.c:88:
undefined reference to `_malloc_r'
/opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-fopen.o):
In function `_fopen_r':
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/fopen.c:141:
undefined reference to `_open_r'
/opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-fseek.o):
In function `_fseek_r':
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/fseek.c:233:
undefined reference to `_fstat_r'
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/fseek.c:258:
undefined reference to `_fstat_r'
/opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-makebuf.o):
In function `__smakebuf_r':
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/makebuf.c:59:
undefined reference to `_fstat_r'
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/makebuf.c:95:
undefined reference to `_malloc_r'
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/makebuf.c:110:
undefined reference to `_isatty_r'
/opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-stdio.o):
In function `__sclose':
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/stdio.c:124:
undefined reference to `_close_r'
/opt/rtems-4.10/lib64/gcc/i386-rtems4.10/4.4.1/../../../../i386-rtems4.10/lib/libc.a(lib_a-stdio.o):
In function `__swrite':
/users/rtems/src/rpms/BUILD/rtems-4.10-i386-rtems4.10-gcc-4.4.1/build/i386-rtems4.10/newlib/libc/stdio/../../../../../gcc-4.4.1/newlib/libc/stdio/stdio.c:86:
undefined reference to `_write_r'
collect2: ld returned 1 exit status
I.e. something still pulls in symbols, RTEMS libc (newlib) doesn't
contain. We still needs stub functions in libc/newlib to let AC_PROG_CC
work out correctly.
Ralf
- Re: AC_PROG_CC fails when target C library is missing fopen, (continued)
- Re: AC_PROG_CC fails when target C library is missing fopen, Adam Sampson, 2009/08/07
- Re: AC_PROG_CC fails when target C library is missing fopen, Paolo Bonzini, 2009/08/07
- Re: AC_PROG_CC fails when target C library is missing fopen, Paolo Bonzini, 2009/08/07
- Re: AC_PROG_CC fails when target C library is missing fopen, Adam Sampson, 2009/08/12
- Re: AC_PROG_CC fails when target C library is missing fopen, Ralf Wildenhues, 2009/08/13
- Re: AC_PROG_CC fails when target C library is missing fopen, Paolo Bonzini, 2009/08/13
Re: AC_PROG_CC fails when target C library is missing fopen, Ralf Wildenhues, 2009/08/10