http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #26 from Eric Botcazou 2012-12-14
18:32:02 UTC ---
> Notice $(srcdir)/gcc/ada/gcc-interface/Makefile.in reads:
>
> # target overrides
> ifneq ($(tmake_file),)
> include $(tmake_file)
> endif
>
> # host overrides
> ifneq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #25 from Georg-Johann Lay 2012-12-14
18:26:07 UTC ---
Created attachment 28960
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28960
Don't use STAMP to please Ada
(In reply to comment #24)
> > What I don't understand is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #24 from Eric Botcazou 2012-12-12
11:35:07 UTC ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #23 from Rolf Ebert 2012-12-11
19:57:34 UTC ---
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. Remin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #22 from Georg-Johann Lay 2012-12-11
12:18:23 UTC ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #21 from Eric Botcazou 2012-12-10
23:13:05 UTC ---
> 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 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #20 from Georg-Johann Lay 2012-12-10
22:57:41 UTC ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #19 from Eric Botcazou 2012-12-10
21:17:52 UTC ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #18 from Georg-Johann Lay 2012-12-10
20:41:15 UTC ---
(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:
>>
>>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #17 from Eric Botcazou 2012-12-10
18:49:19 UTC ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #16 from Eric Botcazou 2012-12-10
18:47:13 UTC ---
> > 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #15 from Georg-Johann Lay 2012-12-10
18:36:33 UTC ---
(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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #14 from Georg-Johann Lay 2012-12-10
18:25:19 UTC ---
(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-gener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #13 from Eric Botcazou 2012-12-10
18:02:19 UTC ---
Created attachment 28916
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28916
Tentative fix for gnatls issue
To be applied in the ada/ source directory.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #12 from Eric Botcazou 2012-12-10
18:00:20 UTC ---
> 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
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #11 from Georg-Johann Lay 2012-12-10
17:00:50 UTC ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #10 from Eric Botcazou 2012-12-03
14:35:35 UTC ---
> 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 m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #9 from Georg-Johann Lay 2012-12-03
13:37:35 UTC ---
(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 si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #8 from Eric Botcazou 2012-12-03
06:39:56 UTC ---
> 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 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
--- Comment #5 from Rolf Ebert 2012-11-17
10:02:49 UTC ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243
Georg-Johann Lay changed:
What|Removed |Added
Component|target |ada
--- Comment #4 from Geor
23 matches
Mail list logo
