For at least two weeks, Ada bootstrap on Solaris/x64 (i.e. the 64-bit-default configuration) is broken: ro@arenal 26 > ../../gnatbind -I- -I../rts -I. -I/vol/gcc/src/hg/trunk/local/gcc/ada -o b_gnatm.adb gnatmake.ali error: "system.ads" has restriction No_Implicit_Dynamic_Code error: but the following files violate this restriction: error: "make.adb" error: "makeutl.adb" error: "prj.adb" error: "prj-env.adb" error: "prj-conf.adb" error: "prj-proc.adb" error: "prj-nmsc.adb" This doesn't happen in sparcv9-sun-solaris2* or i386-pc-solaris2* configurations. Rainer
> This doesn't happen in sparcv9-sun-solaris2* or i386-pc-solaris2* > configurations. gcc-interface/Makefile.in was a little changed so you probably need to adjust the relevant regexp here: # x86 and x86-64 solaris ifeq ($(strip $(filter-out %86 %x86_64 solaris2%,$(arch) $(osys))),) LIBGNAT_TARGET_PAIRS_COMMON = \
> --- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-05-06 16:55:04 UTC --- >> This doesn't happen in sparcv9-sun-solaris2* or i386-pc-solaris2* >> configurations. > > gcc-interface/Makefile.in was a little changed so you probably need to adjust > the relevant regexp here: > > # x86 and x86-64 solaris > ifeq ($(strip $(filter-out %86 %x86_64 solaris2%,$(arch) $(osys))),) > LIBGNAT_TARGET_PAIRS_COMMON = \ That was it indeed. The following patch restored amd64-pc-solaris2.10 bootstrap for, and also survived i386-pc-solaris2.11 bootstrap: diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -1098,7 +1098,7 @@ ifeq ($(strip $(filter-out sparc% sun so endif # x86 and x86-64 solaris -ifeq ($(strip $(filter-out %86 %x86_64 solaris2%,$(arch) $(osys))),) +ifeq ($(strip $(filter-out %86 %x86_64 %amd64 solaris2%,$(arch) $(osys))),) LIBGNAT_TARGET_PAIRS_COMMON = \ a-intnam.ads<a-intnam-solaris.ads \ s-inmaop.adb<s-inmaop-posix.adb \ But what's the justification for the relevant change, which wasn't posted to gcc-patches AFAICS? 2013-04-23 Eric Botcazou <ebotcazou@adacore.com> Pascal Obry <obry@adacore.com> * gcc-interface/Makefile.in (targ): Fix target name check. Having to deal with the target_alias instead of the canonical form found in target seems rather counterintuitive and fragile to me. Rainer
> But what's the justification for the relevant change, which wasn't > posted to gcc-patches AFAICS? > > 2013-04-23 Eric Botcazou <ebotcazou@adacore.com> > Pascal Obry <obry@adacore.com> > > * gcc-interface/Makefile.in (targ): Fix target name check. > > Having to deal with the target_alias instead of the canonical form found > in target seems rather counterintuitive and fragile to me. The ChangeLog entry is misleading, neither Pascal nor I have anything to do with the change. Yes, this is very fragile and has already caused various issues.
> --- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-05-07 > 15:06:45 UTC --- >> But what's the justification for the relevant change, which wasn't >> posted to gcc-patches AFAICS? >> >> 2013-04-23 Eric Botcazou <ebotcazou@adacore.com> >> Pascal Obry <obry@adacore.com> >> >> * gcc-interface/Makefile.in (targ): Fix target name check. >> >> Having to deal with the target_alias instead of the canonical form found >> in target seems rather counterintuitive and fragile to me. > > The ChangeLog entry is misleading, neither Pascal nor I have anything to do > with the change. Yes, this is very fragile and has already caused various > issues. This seems to argue for reverting or at least reworking the change. I suppose I'll withhold my patch until it's decided how to proceed. Rainer
> This seems to argue for reverting or at least reworking the change. I > suppose I'll withhold my patch until it's decided how to proceed. I'd post it on the list in any case and see what the other maintainers think.
Mine, patch posted.
> >> * gcc-interface/Makefile.in (targ): Fix target name check. > >> > >> Having to deal with the target_alias instead of the canonical form found > >> in target seems rather counterintuitive and fragile to me. > > > > The ChangeLog entry is misleading, neither Pascal nor I have anything to > > do > > with the change. Yes, this is very fragile and has already caused various > > issues. > > This seems to argue for reverting or at least reworking the change. I > suppose I'll withhold my patch until it's decided how to proceed. This change is useful for many cross configurations which have similar names, so I would suggest you post your patch to gcc-patches@. Your patch is pre-approved FWIW, so feel free to apply it. Arno
Fixed for 4.9.0.