Building AVR cross compiler for Ada (GNAT) fails as t-avr contains no valid command in the STAMP variable easiest work-around is to replace it with 'echo' command. sed -i -e 's/$(STAMP)/echo timestamp >/' gcc/config/avr/t-avr
STAMP should be set. Can you provide the full log of the error?
A complete build instruction is in http://arduino.ada-language.com/building-avr-gnat-for-avr-ada.html I'll add a make output without the patch once I can build again (probably tomorrow)
Here is the requested build log: make[2]: Entering directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gnattools' rm -rf ../gcc/ada/tools mkdir -p ../gcc/ada/tools (cd ../gcc/ada/tools; cp -p ../sdefault.adb ../snames.ads ../snames.adb .) rm -f ../gcc/ada/tools/mlib-tgt-specific.adb; cp -p /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada/mlib-tgt-specific-xi.adb ../gcc/ada/tools/mlib-tgt-specific.adb; rm -f ../gcc/ada/tools/indepsw.adb; cp -p /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada/indepsw-gnu.adb ../gcc/ada/tools/indepsw.adb; touch ../gcc/stamp-tools # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ "CC=gcc" "CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall" "LDFLAGS=-Wl,--stack,12582912" "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../.. -I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada -I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config -I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/../include -I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc" "ADA_INCLUDES=-IC:/Programme/MinGW2011/local/lib/gcc/mingw32/4.7.0/adalib/../adainclude -IC:/Programme/MinGW2011/local/lib/gcc/mingw32/4.7.0/adalib/ -I. -I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada" "exeext=.exe" "fsrcdir=/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc" "srcdir=/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind" "TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \ gnatmake-re gnatlink-re make[3]: Entering directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gcc/ada/tools' gawk -f /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/genmultilib.awk -v FORMAT=Makefile /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/genmultilib.awk /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/avr-mcus.def > tmp-avr-mlib /bin/sh /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/../move-if-change \ tmp-avr-mlib /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/t-multilib s-avr-mlib make[3]: s-avr-mlib: Command not found make[3]: *** [s-avr-mlib] Error 127 make[3]: Leaving directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gcc/ada/tools' make[2]: *** [gnattools-cross] Error 2 make[2]: Leaving directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gnattools' make[1]: *** [all-gnattools] Error 2 make[1]: Leaving directory `/c/Devel/gcc-cvs.not/build/gcc-obj' make: *** [all] Error 2
t-avr is the wrong place to set STAMP, it should be set in some Makefile(.in), presumable in the ada part, somewhere around ./gcc/ada/gcc-interface/Makefile.in You see STAMP being mentioned in repsective config.log?
STAMP isn't set by configure. It is rather hardcoded in gcc/Makefile.in Correspondignly it has to be set in gnattools/Makefile.in, too: --- gnattools/Makefile.in~ 2011-10-13 00:41:57 +0200 +++ gnattools/Makefile.in 2012-11-16 20:50:48 +0100 @@ -111,6 +111,7 @@ "GNATMAKE=gnatmake" \ "GNATLINK=gnatlink" \ "GNATBIND=gnatbind" \ + "STAMP=echo timestamp >" \ "TOOLSCASE=cross" \ "LIBGNAT="
The GNAT tools are for the host, they have nothing to do with multilibs. How come the s-avr-mlib Makefile rule gets invoked here?
(In reply to comment #6) > The GNAT tools are for the host, they have nothing to do with multilibs. How > come the s-avr-mlib Makefile rule gets invoked here? avr-gcc supports around 200 devices. In order to keep the various parts of the compiler in sync, some files are auto-generated from the device description in $(srcdir)/config/avr/avr-mcus.def. $(srcdir)/config/avr/t-avr reads: ... AVR_MCUS = $(srcdir)/config/avr/avr-mcus.def ... # MULTILIB_OPTIONS # MULTILIB_DIRNAMES # MULTILIB_EXCEPTIONS # MULTILIB_MATCHES $(srcdir)/config/avr/t-multilib: s-avr-mlib; @true s-mlib: $(srcdir)/config/avr/t-multilib s-avr-mlib: $(srcdir)/config/avr/genmultilib.awk $(AVR_MCUS) $(AWK) -f $< -v FORMAT=Makefile $< $(AVR_MCUS) > tmp-avr-mlib $(SHELL) $(srcdir)/../move-if-change \ tmp-avr-mlib $(srcdir)/config/avr/t-multilib $(STAMP) $@ And in config.gcc there is tmake_file="avr/t-avr avr/t-multilib" Thus, the assumption is that AWK, SHELL and STAMP are set correctly and respective tools are available on the build platform.
> And in config.gcc there is > > tmake_file="avr/t-avr avr/t-multilib" > > > Thus, the assumption is that AWK, SHELL and STAMP are set correctly and > respective tools are available on the build platform. OK, but the question is why this rule is invoked during the gnattools build? Moreover, why does s-avr-mlib need to be rebuilt at this point since it has presumably already been built for the target libraries?
(In reply to comment #8) > OK, but the question is why this rule is invoked during the gnattools build? > Moreover, why does s-avr-mlib need to be rebuilt at this point since it has > presumably already been built for the target libraries? I don't know anything about the gnat build system and when I build avr-gcc I configure for C/C++. What's odd is that even if GCC is only configured for C/C++, I get messages about a missing gnatls. For example, running make in the gcc subdirectory of build prints $build/gcc> make /bin/sh: gnatls: command not found The build itself works fine but that message is confusing and shows that something is wrong with the gnat build system. gnat stuff should not be needed of the compiler is not configured for ada, should it?
> I don't know anything about the gnat build system and when I build avr-gcc I > configure for C/C++. > > What's odd is that even if GCC is only configured for C/C++, I get messages > about a missing gnatls. For example, running make in the gcc subdirectory of > build prints > > $build/gcc> make > /bin/sh: gnatls: command not found > > The build itself works fine but that message is confusing and shows that > something is wrong with the gnat build system. > > gnat stuff should not be needed of the compiler is not configured for ada, > should it? Probably, but if nobody really investigates, nothing will ever be fixed.
(In reply to comment #10) >> I don't know anything about the gnat build system and when I build avr-gcc I >> configure for C/C++. >> >> What's odd is that even if GCC is only configured for C/C++, I get messages >> about a missing gnatls. For example, running make in the gcc subdirectory of >> build prints >> >> $build/gcc> make >> /bin/sh: gnatls: command not found >> >> The build itself works fine but that message is confusing and shows that >> something is wrong with the gnat build system. >> >> gnat stuff should not be needed of the compiler is not configured for ada, >> should it? > > Probably, but if nobody really investigates, nothing will ever be fixed. $(build)/gcc/Makefile reads: # per-language makefile fragments ifneq ($(LANG_MAKEFRAGS),) include $(LANG_MAKEFRAGS) endif # target and host overrides must follow the per-language makefile fragments # so they can override or augment language-specific variables # target overrides ifneq ($(tmake_file),) include $(tmake_file) endif LANG_MAKEFRAGS contains $(srcdir)/ada/gcc-interface/Make-lang.in which in turn contains: # put the host RTS dir first in the PATH to hide the default runtime # files that are among the sources RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) which means gnatls is called no matter if it exists or not. (In reply to comment #6) > The GNAT tools are for the host, they have nothing to do with multilibs. > How come the s-avr-mlib Makefile rule gets invoked here? The Makefile includes $(tmake_file) and thus $(srcdir)/gcc/config/avr/t-multilib which is auto-generated and needs $(STAMP) to build. AFAIK make resolves its includes before it starts building the targets.
> LANG_MAKEFRAGS contains $(srcdir)/ada/gcc-interface/Make-lang.in which in turn > contains: > > # put the host RTS dir first in the PATH to hide the default runtime > # files that are among the sources > RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) > > which means gnatls is called no matter if it exists or not. OK, thanks for investigating. Tentative patch for ada/ to be attached. > The Makefile includes $(tmake_file) and thus > $(srcdir)/gcc/config/avr/t-multilib which is auto-generated and needs $(STAMP) > to build. > > AFAIK make resolves its includes before it starts building the targets. So t-multilib is autogenerated in the source tree during the build???
Created attachment 28916 [details] Tentative fix for gnatls issue To be applied in the ada/ source directory.
(In reply to comment #12) > So t-multilib is autogenerated in the source tree during the build??? Jepp. Top $(srcdir)/gcc/config/avr/t-multilib reads: # Auto-generated Makefile Snip # Generated by : ./gcc/config/avr/genmultilib.awk # Generated from : ./gcc/config/avr/avr-mcus.def # Used by : tmake_file from Makefile and genmultilib Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=<device>. In order to keep various parts of the compiler in sync, some bits are auto-generated, amongst them documentation, t-multilib and .opt parts. Procedure is a move-if-change scheme, i.e. the auto-generated files are in the repository and the procedure to build them is similar to building configure from configure.ac and then putting both configure.ac /and/ configure into the repo. However, the auto-build runs automatically and thus needs some tools, namely $(SHELL), $(AWK), $(CC_FOR_BUILD), $(RUN_GEN) and $(STAMP).
(In reply to comment #13) > Created attachment 28916 [details] > Tentative fix for gnatls issue > > To be applied in the ada/ source directory. This works for me with, i.e. the /bin/sh: gnatls: command not found is gone. $ ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 --enable-target-optspace=yes --enable-languages=c,c++ build: i686-pc-linux-gnu host: i686-pc-linux-gnu target: avr-unknown-none Someone else will have to test if it works if Ada is on. BTW, today is Ada's birthday :-)
> > So t-multilib is autogenerated in the source tree during the build??? > > Jepp. Top $(srcdir)/gcc/config/avr/t-multilib reads: > > > # Auto-generated Makefile Snip > # Generated by : ./gcc/config/avr/genmultilib.awk > # Generated from : ./gcc/config/avr/avr-mcus.def > # Used by : tmake_file from Makefile and genmultilib But this is a no-no, the compiler should be buildable with read-only sources once it is packaged in the release tarballs. > Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=<device>. > In order to keep various parts of the compiler in sync, some bits are > auto-generated, amongst them documentation, t-multilib and .opt parts. > > Procedure is a move-if-change scheme, i.e. the auto-generated files are in the > repository and the procedure to build them is similar to building configure > from configure.ac and then putting both configure.ac /and/ configure into the > repo. Building configure from configure.c isn't done at build time. Either you generate t-multilib like configure and you can put it in $(srcdir) or you generate it at build time and you must put it in $(builddir).
> This works for me with, i.e. the > /bin/sh: gnatls: command not found > is gone. > > $ ../../gcc.gnu.org/trunk/configure --target=avr > --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 > --enable-target-optspace=yes --enable-languages=c,c++ > > build: i686-pc-linux-gnu > host: i686-pc-linux-gnu > target: avr-unknown-none > > Someone else will have to test if it works if Ada is on. BTW, today is Ada's > birthday :-) It works. Thanks for testing, I'm going to apply it on the mainline.
(In reply to comment #16) >>> So t-multilib is autogenerated in the source tree during the build??? >> >> Jepp. Top $(srcdir)/gcc/config/avr/t-multilib reads: >> >> >> # Auto-generated Makefile Snip >> # Generated by : ./gcc/config/avr/genmultilib.awk >> # Generated from : ./gcc/config/avr/avr-mcus.def >> # Used by : tmake_file from Makefile and genmultilib > > But this is a no-no, the compiler should be buildable with read-only sources > once it is packaged in the release tarballs. It works with read-only sources, provided everything is consistent. Or are you saying that a t-snip must not use $(STAMP)? Actually, the PR boils down to the fact the STAMP is not defined, I am nut sure if the compiler is supposed to build without STAMP. >> Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=<device>. >> In order to keep various parts of the compiler in sync, some bits are >> auto-generated, amongst them documentation, t-multilib and .opt parts. >> >> Procedure is a move-if-change scheme, i.e. the auto-generated files are in the >> repository and the procedure to build them is similar to building configure >> from configure.ac and then putting both configure.ac /and/ configure into the >> repo. > > Building configure from configure.c isn't done at build time. > > Either you generate t-multilib like configure and you can put it in $(srcdir) > or you generate it at build time and you must put it in $(builddir). Is basically follows an idea introduced with genopt.sh in http://gcc.gnu.org/viewcvs?view=revision&revision=175248 Notice how t-avr builds avr-tables.opt, and that the latter is added to the repo.
> It works with read-only sources, provided everything is consistent. Or are > you saying that a t-snip must not use $(STAMP)? I'm saying that the build process should never touch the source tree. > Actually, the PR boils down to the fact the STAMP is not defined, I am nut > sure if the compiler is supposed to build without STAMP. Probably not, but what I'm trying to understand is why we seem to be fiddling with the source tree when building the gnattools. > Is basically follows an idea introduced with genopt.sh in > > http://gcc.gnu.org/viewcvs?view=revision&revision=175248 > > Notice how t-avr builds avr-tables.opt, and that the latter is added to the > repo. The point is that, if a file is present in the repo, it should not be generated at build time, but only when it is updated in the repo.
(In reply to comment #19) >> It works with read-only sources, provided everything is consistent. Or are >> you saying that a t-snip must not use $(STAMP)? > > I'm saying that the build process should never touch the source tree. Isn't ./gcc/doc/md.texi both in the repo and generated (from ./gcc/doc/md.texi.in)? And, if parts of the docs are changed you will we nagged to verify GFDL and to copy the new, auto-generated parts in place? >> Actually, the PR boils down to the fact the STAMP is not defined, I am not >> sure if the compiler is supposed to build without STAMP. > > Probably not, but what I'm trying to understand is why we seem to be fiddling > with the source tree when building the gnattools. As far as gnattools are concerned, it makes no difference whether the auto-generated files are stamped and written to $build or stamped and written to $source. I agree that the $source vs. $build matter should be cleaned up. However, that won't help with this PR because the rules and the dependencies and the needed tools will remain the same.
> As far as gnattools are concerned, it makes no difference whether the > auto-generated files are stamped and written to $build or stamped and written > to $source. > > I agree that the $source vs. $build matter should be cleaned up. > > However, that won't help with this PR because the rules and the dependencies > and the needed tools will remain the same. So we're back to square one: why on Earth does this file need to be regenerated when the gnattools are built, since it has already been generated previously during the build (in addition to being already present in the source tree)?
(In reply to comment #21) What I don't understand is what is bad with Rolf's proposal of defining STAMP? Stamping is not that unusual in the build process. Up to now it was not needed, but is it that critical to set STAMP like proposed above?
I see Eric's point in that the patch in comment #5 hides another bug in the Makefile chemistry. There seems to be an unnecessary dependency from the gnattools on multilibs. Reminds me of #19959
> What I don't understand is what is bad with Rolf's proposal of defining STAMP? We simply don't need to stamp anything for the gnattools. > Stamping is not that unusual in the build process. Up to now it was not > needed, but is it that critical to set STAMP like proposed above? Well, building the gnattools works flawlessly for all targets except for AVR, because of a very questionable kludge. So it makes sense to fix the kludge.
Created attachment 28960 [details] Don't use STAMP to please Ada (In reply to comment #24) > > What I don't understand is what is bad with Rolf's proposal of defining STAMP? > > We simply don't need to stamp anything for the gnattools. Notice $(srcdir)/gcc/ada/gcc-interface/Makefile.in reads: # target overrides ifneq ($(tmake_file),) include $(tmake_file) endif # host overrides ifneq ($(xmake_file),) include $(xmake_file) endif There are other backends like x86 and mips that use STAMP in their t-snip, so I wonder how you can conclude that ada does not include code that might require STAMP? Here is a patch that bypasses the need of STAMP in t-avr. Rolf can test it. PR55243 * config/avr/t-avr: Don't automatically rebuild $(srcdir)/config/avr/t-multilib $(srcdir)/config/avr/avr-tables.opt $(srcdir)/doc/avr-mmcu.texi (avr-mcus): New phony target to build them on request. (s-avr-mlib, s-avr-mmcu-texi): Remove. * avr/avr-mcus.def: Adjust comments.
> Notice $(srcdir)/gcc/ada/gcc-interface/Makefile.in reads: > > # target overrides > ifneq ($(tmake_file),) > include $(tmake_file) > endif > > # host overrides > ifneq ($(xmake_file),) > include $(xmake_file) > endif > > There are other backends like x86 and mips that use STAMP in their t-snip, so > I wonder how you can conclude that ada does not include code that might > require STAMP? I didn't say that though, rather that we don't need STAMP for the gnattools. Of course we need it for the Ada compiler proper, like the other compilers. > Here is a patch that bypasses the need of STAMP in t-avr. Rolf can test it. > > > PR55243 > * config/avr/t-avr: Don't automatically rebuild > $(srcdir)/config/avr/t-multilib > $(srcdir)/config/avr/avr-tables.opt > $(srcdir)/doc/avr-mmcu.texi > (avr-mcus): New phony target to build them on request. > (s-avr-mlib, s-avr-mmcu-texi): Remove. > * avr/avr-mcus.def: Adjust comments. Nice, thanks.
.
Created attachment 28988 [details] Backport of gjl's patch to 4.7 I had to backport Georg's patch to 4.7.2. It perferctly solves the issue and I can build the AVR cross for Ada Rolf
(In reply to comment #24) >> What I don't understand is what is bad with Rolf's proposal of defining STAMP? > > We simply don't need to stamp anything for the gnattools. > >> Stamping is not that unusual in the build process. Up to now it was not >> needed, but is it that critical to set STAMP like proposed above? > > Well, building the gnattools works flawlessly for all targets except for AVR, That argument doues not count, IMO. Almost nothing in GCC was added without precedent: Features were added because backend X needed them or frontend Y needed them. To reject an extension just because only one target needs it, is not an convincing argument. It's still not known why the ada / gnat stuff rebuilds stuff already there a sectons time and at a stage ada / gnat don't expect such a build. Throwing out the need of STAMP works, but it does not answer the question why ada does things it does not expect at a stage it does not expect. (In reply to comment #26) >> There are other backends like x86 and mips that use STAMP in their t-snip, so >> I wonder how you can conclude that ada does not include code that might >> require STAMP? > >I didn't say that though, rather that we don't need STAMP for the gnattools. If I understand correctly, someone familiar with the gnat build machiney and philosophy might want to find out why it performs a mistimed rebuild of things that are elready supposed to be there? BTW, avr/t-multilib cannot be generated from scratch in the build directory because it is included in Makefile. The dependencies in gcc_update:files_and_dependencies() look reasonable.
> Almost nothing in GCC was added without precedent: Features were added because > backend X needed them or frontend Y needed them. To reject an extension just > because only one target needs it, is not an convincing argument. I totally disagree of course. You must first try to fit in the existing design and, only when that fails, you're allowed to propose extensions. > It's still not known why the ada / gnat stuff rebuilds stuff already there a > sectons time and at a stage ada / gnat don't expect such a build. Indeed. > If I understand correctly, someone familiar with the gnat build machiney and > philosophy might want to find out why it performs a mistimed rebuild of things > that are elready supposed to be there? Yes, that's the crux of the matter.
Author: gjl Date: Mon Jan 7 13:12:10 2013 New Revision: 194970 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194970 Log: Backport from 2013-01-07 trunk r194968. PR other/55243 * config/avr/t-avr: Don't automatically rebuild $(srcdir)/config/avr/t-multilib $(srcdir)/config/avr/avr-tables.opt (avr-mcus): New phony target to build them on request. (s-avr-mlib): Remove. * avr/avr-mcus.def: Adjust comments. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr-mcus.def branches/gcc-4_7-branch/gcc/config/avr/t-avr
Fixed for 4.7.3 Change set for trunk: http://gcc.gnu.org/viewcvs?view=revision&revision=194968