Bug 13076 - gnatlib can't be built cross
Summary: gnatlib can't be built cross
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: ada (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-16 17:17 UTC by corsepiu
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: any
Target: newlib
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description corsepiu 2003-11-16 17:17:40 UTC
configure --target=i386-rtems --enable-languages=c,ada --with-newlib ...

# make -C gcc gnatlib
...
../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC   `echo -g -O2  -fexceptions -DI
N_RTS |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'`      \
         -I. -I.. -I../.. -I/users/rtems/src/packages/BUILD/rtems-4.7-i386-rtems
4.7-gcc-newlib-gcc3.3.2newlib1.11.0/gcc-3.3.2/gcc/ada -I/users/rtems/src/package
s/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc3.3.2newlib1.11.0/gcc-3.3.2/gcc/ad
a/.. -I/users/rtems/src/packages/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc3.3
.2newlib1.11.0/gcc-3.3.2/gcc/ada/../config -I/users/rtems/src/packages/BUILD/rte
ms-4.7-i386-rtems4.7-gcc-newlib-gcc3.3.2newlib1.11.0/gcc-3.3.2/gcc/ada/../../inc
lude -I./../.. -I/users/rtems/src/packages/BUILD/rtems-4.7-i386-rtems4.7-gcc-new
lib-gcc3.3.2newlib1.11.0/gcc-3.3.2/gcc/ada/../.. -I../.. \
      -DPREFIX=\"/opt/rtems-4.7\" /users/rtems/src/packages/BUILD/rtems-4.7-i386
-rtems4.7-gcc-newlib-gcc3.3.2newlib1.11.0/gcc-3.3.2/gcc/ada/../prefix.c
In file included from /users/rtems/src/packages/BUILD/rtems-4.7-i386-rtems4.7-gc
c-newlib-gcc3.3.2newlib1.11.0/gcc-3.3.2/gcc/prefix.c:69:
/users/rtems/src/packages/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc3.3.2newli
b1.11.0/gcc-3.3.2/gcc/system.h:117:22: strings.h: No such file or directory
make[2]: *** [prefix.o] Error 1

Apparent cause is prefix.c including config.h, which subsequently includes
auto-host.h.

auto-host.h contains the configure-detected values for the build-host, not for
the target as building gnatlib assumes

=> gnatlib is being compiled by the cross-compiler, using the configuation
values having been detected for the build-host

=> gnatlib can not be cross-compiled for *any* target.
Comment 1 Arnaud Charlet 2003-11-17 07:51:43 UTC
Your comment is incorrect, gnatlib will build on many
cross configuration, even if it is conceptually wrong to build prefix.c
with auto-host on the target.

The work around is to provide a strings.h

This is fixed in the mainline.

Arno
Comment 2 corsepiu 2003-11-17 08:46:20 UTC
I think you didn't understand.

Given the implementation in gcc-3.3, gnatlib by no means can be cross-compiled,
because it is a misconception to include auto-host.h into any target-file.

If you manage to build it cross, it's only because, by accident your host and
target resembles enough for not provoking an error.

Building choking on not having found strings.h is only the symptom, not the
cause, because the host (linux) has strings.h, but the target (rtems/newlib)
doesn't have it.

This bug might be fixed in gcc-3.4 or not (I don't know, gcc-3.4 currently is
too volatile), it still is present in gcc-3.3.

Comment 3 charlet 2003-11-17 09:18:26 UTC
Subject: Re:  gnatlib can't be built cross

> Given the implementation in gcc-3.3, gnatlib by no means can be cross-compiled,
> because it is a misconception to include auto-host.h into any target-file.
> 
> If you manage to build it cross, it's only because, by accident your host and
> target resembles enough for not provoking an error.

I know, and this is exactly what I said in my previous message.
Given that prefix.o is actually not used afterwards, simply getting it to
compile is enough to solve this issue.

Another work around is to simply remove prefix.o from the libgnat objects.

Anyway, do whatever you like with this PR, you now have all the cards in
your hands.

Arno
Comment 4 Andrew Pinski 2003-11-17 14:15:37 UTC
This bug is not going to be fixed for 3.3, Ada will remain boken for newlib, just create a strings.h 
file and the problem is solved.