Hi, with gcc-3.4.3 its possible to compile the gnat crosstools with a simple 'make cross-gnattools'. This no longer works for 4.0.0. (20050213) I've tried this: $ ../configure --target=avr --enable-languages=ada,c [..] $ make [..] it stops here: make[3]: Entering directory `/src/gcc/obj/gcc/ada/rts' ../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2 -DDF=SF -Dinhibit_libc -mcall-prologues -fexceptions -DIN_RTS |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` -I. -I.. -I../.. -I/src/gcc/gcc/ada -I/src/gcc/gcc/ada/../config -I/src/gcc/gcc/ada/../../include -I/src/gcc/gcc/ada/.. -I./../.. adaint.c -o adaint.o adaint.c:61:22: error: sys/stat.h: No such file or directory adaint.c:62:19: error: fcntl.h: No such file or directory adaint.c:63:18: error: time.h: No such file or directory adaint.c:82:19: error: utime.h: No such file or directory adaint.c:91:22: error: sys/wait.h: No such file or directory In file included from adaint.c:154: [..] adaint.c:2040: warning: initialization makes pointer from integer without a castadaint.c:2057: warning: incompatible implicit declaration of built-in function 'strcpy' adaint.c: In function '__gnat_copy_attribs': adaint.c:2555: error: storage size of 'fbuf' isn't known adaint.c:2556: error: storage size of 'tbuf' isn't known make[3]: *** [adaint.o] Error 1 make[3]: Leaving directory `/src/gcc/obj/gcc/ada/rts' make[2]: *** [gnatlib] Error 2 make[2]: Leaving directory `/src/gcc/obj/gcc/ada' make[1]: *** [gnatlib-plain] Error 2 make[1]: Leaving directory `/src/gcc/obj/avr/libada' make: *** [all-target-libada] Error 2 gcc version 4.0.0 20050213
Nathanael, do you know why the rts gets compiled here? (the avr target does not have a rts)
Fails for --target=i386-elf too.
(In reply to comment #2) > Fails for --target=i386-elf too. but that is more likely PR 6852.
Please see http://www.rtems.com/phpwiki/index.php/RTEMSAda for instructions on how to build a cross with Ada enabled (this is for RTEMS but should be reusable).
Subject: Re: [4.0/4.1 Regression] Can't compile gnattools for the cross targets laurent at guerby dot net wrote: >------- Additional Comments From laurent at guerby dot net 2005-02-28 21:54 ------- >Please see http://www.rtems.com/phpwiki/index.php/RTEMSAda >for instructions on how to build a cross with Ada enabled >(this is for RTEMS but should be reusable). > > > If you look closely at the bug report, the target is for the AVR, which uses avr-libc and NOT newlib. The OP is working on the AVR-Ada project: <http://sourceforge.net/projects/avr-ada>
Update: with this patch to $TARGET/libada/Makefile RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) -gnattools-cross: gnatlib +gnattools-cross: $(MAKE) -C $(GCC_DIR)/ada $(FLAGS_TO_PASS) $(ADA_FLAGS_TO_PASS) \ and cd $TARGET/libada make gnattools-cross I get the cross gnattools compiled (without newlib).
Confirmed, due to incorrect dependency in gnattools/Makefile.in Fixing...
Subject: Bug 19959 CVSROOT: /cvs/gcc Module name: gcc Changes by: charlet@gcc.gnu.org 2005-03-30 08:56:57 Modified files: gnattools : Makefile.in Log message: PR ada/19959 * Makefile.in (gnattools-cross): Remove incorrect dependency on gnatlib Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gnattools/Makefile.in.diff?cvsroot=gcc&r1=1.3&r2=1.4
Should be fixed now.
Arnaud Charlet wrote: >Should be fixed now. Can you please describe how you tested the patch? I still get the errors in 4_0-branch and head! Why does the '--disable-libada' switch disable gnattools-cross?
Ada is not release-critical.
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
> Why does the '--disable-libada' switch disable gnattools-cross? libada and gnattools-cross are not related, IMHO. I consider the dependancy as a configure/Makefile bug. The following patch removes the dependency of gnattols on libada. --- gcc-4.2-20061226/configure~ Sun Dec 10 22:43:30 2006 +++ gcc-4.2-20061226/configure Thu Jan 4 10:15:19 2007 @@ -1136,9 +1136,6 @@ ENABLE_LIBADA=yes fi -if test "${ENABLE_LIBADA}" != "yes" ; then - noconfigdirs="$noconfigdirs gnattools" -fi # Check whether --enable-libssp or --disable-libssp was given. if test "${enable_libssp+set}" = set; then If you configure now with --disable-libada, the cross-gnattols get properly built. Tested on MinGW with gcc-4.2-20061226 targeting AVR. Rolf
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the cross targets > libada and gnattools-cross are not related, IMHO. I consider the dependancy as > a configure/Makefile bug. > > The following patch removes the dependency of gnattols on libada. Given that you apparently cannot build gnatlib, you could instead do a make -C gcc gnattools or similar --disable-libada is intended to disable both gnatlib and gnattools (and should perhaps be renamed), so this is not a bug. Your proposed patch removes a useful capability. At the very least, gnattools should be disabled in the case of native builds when using --disable-libada Arno
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the cross targets BTW, answering an old message: << Can you please describe how you tested the patch? >> No test since I do not have a set up for avr, it was an obvious change. << Why does the '--disable-libada' switch disable gnattools-cross? >> This has nothing to do with this PR however, which is not about --disable-libada. Let's please keep issues separate; thanks. If you have troubles with --disable-libada, you should open another PR. Arno
After reviewing this ticket, I am coming to the conclusion that things are working "as expected" now: due to major changes in the gcc directory structure and makefiles, when you do a make, GCC will always build gnatlib and gnattools, so things are working as expected, except that gnatlib is not working on AVR (which is a different issue). The fix I made to gnattools-cross is still good: gnattools-cross does not depend on gnatlib, unlike the native case. Arno
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.