This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
bug in newlib's configury
- To: "newlib at sources dot redhat dot com" <newlib at sources dot redhat dot com>
- Subject: bug in newlib's configury
- From: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>
- Date: Fri, 05 Jan 2001 13:02:41 +0100
- CC: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- Organization: Ralf Corsepius
- Reply-To: corsepiu at faw dot uni-ulm dot de
Hi,
when configuring newlib standalone (no one-tree style building),
this happens:
# ../newlib-1.9.0/configure --target=sh-rtems --prefix=/tmp/foo
--disable-multilib
..
# make
..
checking for gcc... sh-rtems-gcc
-B/home/rtems/build/sh-rtems/newlib/
-isystem /home/rtems/build/sh-rtems/newlib/targ-include
-isystem /home/rtems/newlib-1.9.0/newlib/libc/include
checking whether we are using GNU C... yes
checking whether sh-rtems-gcc -B/home/rtems/build/sh-rtems/newlib/
-isystem /home/rtems/build/sh-rtems/newlib/targ-include
-isystem /home/rtems/newlib-1.9.0/newlib/libc/include
accepts -g... no
..
=> configure fails to detect -g.
The cause seems to be an "file path prefix .. never used" warning
from gcc causing the autoconf check to fail.
# sh-rtems-gcc -B/home/rtems/build/sh-rtems/newlib/ -isystem
/home/rtems/build/sh-rtems/newlib/targ-include -isystem
/home/rtems/newlib-1.9.0/newlib/libc/include -g -c conftest.c
sh-rtems-gcc: file path prefix `/home/rtems/build/sh-rtems/newlib/'
never used
AFAIS, this seems to be caused by the way Cygnus configure.in sets
up FLAGS_FOR_TARGET (configure.in:1326):
> ..
> FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/newlib/
> ..
Removing -B../newlib/ from this line fixes this problem for newlib,
but I suspect this would break building gcc or other packages
applying Cygnus configure.in.
Ralf