[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #56 from Eric Botcazou  ---
> Fixed in the trunk.  Does anyone care enough to backport it?

I don't think that there is a need for it.  Thanks for sorting this out!

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #55 from Alexandre Oliva  ---
Fixed in the trunk.  Does anyone care enough to backport it?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #54 from Alexandre Oliva  ---
Author: aoliva
Date: Tue Nov 20 00:07:47 2018
New Revision: 266290

URL: https://gcc.gnu.org/viewcvs?rev=266290=gcc=rev
Log:
PR81878: fix --disable-bootstrap --enable-languages=ada

gnattools build machinery uses just-build xgcc and xg++ as $(CC) and
$(CXX) in native builds.  However, if C and C++ languages are not
enabled, it won't find them.  So, enable C and C++ if Ada is enabled.
Most of the time, this is probably no big deal: C is always enabled
anyway, and C++ is already enabled for bootstraps.

We need not enable those for cross builds, however.  At first I just
took the logic from gnattools/configure, but found it to be lacking:
it would use the just-built tools even in cross-back settings, whose
tools just built for the host would not run on the build machine.  So
I've narrowed down the test to rely on autoconf-detected cross-ness
(build->host only), but also to ensure that host matches build, and
that target matches host.

I've considered sourcing ada/config-lang.in from within
gnattools/configure, and testing lang_requires as set by it, so as to
avoid a duplication of tests that ought to remain in sync, but decided
it would be too fragile, as ada/config-lang.in does not expect srcdir
to refer to gnattools.

for  gcc/ada/ChangeLog

PR ada/81878
* gcc-interface/config-lang.in (lang_requires): Set to "c c++"
when gnattools wants it.

for  gnattools/ChangeLog

PR ada/81878
* configure.ac (default_gnattools_target): Do not mistake
just-built host tools as native in cross-back toolchains.
* configure: Rebuilt.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/config-lang.in
trunk/gnattools/ChangeLog
trunk/gnattools/configure
trunk/gnattools/configure.ac

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #53 from Alexandre Oliva  ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00930.html

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #52 from Eric Botcazou  ---
> for native builds, I mean.  hmm, I wonder if we can test for a native build
> in config-lang.in...

Yes, that would be ideal.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #51 from Alexandre Oliva  ---
for native builds, I mean.  hmm, I wonder if we can test for a native build in
config-lang.in...

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #50 from Alexandre Oliva  ---
Do we want lang_requires="c c++" in ada's config-lang.in, then?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #49 from Eric Botcazou  ---
> But doesn't reverting everything will bring it back to the state it was
> before, in that `--disable-bootstrap` is still broken.

No, --disable-bootstrap alone works fine, see the subject of the PR.

> A proper fix is needed here, would changing the way gnatlink receives it's
> arguments be acceptable? Not quoting them would solve the problem for both
> platforms along with Richard's original patch.

No, I don't think that we want this kind of earthquakes in gnatlink.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #48 from Tamar Christina  ---
But doesn't reverting everything will bring it back to the state it was before,
in that `--disable-bootstrap` is still broken.

So it seems we have two seemingly incompatible behaviors.
the fix for `--disable-bootstrap` breaks any and all Windows build variants.
the simple fix for Windows support seems to break --disable-bootstrap on Linux
again.

A proper fix is needed here, would changing the way gnatlink receives it's
arguments be acceptable? Not quoting them would solve the problem for both
platforms along with Richard's original patch.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #47 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov  6 08:43:10 2018
New Revision: 265831

URL: https://gcc.gnu.org/viewcvs?rev=265831=gcc=rev
Log:
PR ada/81878
Revert
2018-11-02  Tamar Christina  

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.

2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
branches/gcc-8-branch/gnattools/ChangeLog
branches/gcc-8-branch/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #46 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Nov  6 08:42:56 2018
New Revision: 265830

URL: https://gcc.gnu.org/viewcvs?rev=265830=gcc=rev
Log:
PR ada/81878
Revert
2018-10-29  Tamar Christina  

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.

2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #45 from Eric Botcazou  ---
> native --disable-bootstrap build on x86_64-linux-gnu now fails on trunk:
> gnattools uses g++ -B../../ to link, which fails because g++ 8 does not
> understand the %@ specs.  We really shouldn't be mixing up the preinstalled
> compiler with the just-built one IMHO: it should be either g++, or
> ../../xg++ -B../../ (probably with additional flags to find libstdc++, if
> that's needed)

OK, let's just revert everything, the cure is clear worse than the disease.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #44 from rguenther at suse dot de  ---
On Tue, 6 Nov 2018, aoliva at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
> 
> Alexandre Oliva  changed:
> 
>What|Removed |Added
> 
>  Status|RESOLVED|REOPENED
>  Resolution|FIXED   |---
> 
> --- Comment #43 from Alexandre Oliva  ---
> native --disable-bootstrap build on x86_64-linux-gnu now fails on trunk:
> gnattools uses g++ -B../../ to link, which fails because g++ 8 does not
> understand the %@ specs.  We really shouldn't be mixing up the preinstalled
> compiler with the just-built one IMHO: it should be either g++, or ../../xg++
> -B../../ (probably with additional flags to find libstdc++, if that's needed)

So what broke this again?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Alexandre Oliva  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #43 from Alexandre Oliva  ---
native --disable-bootstrap build on x86_64-linux-gnu now fails on trunk:
gnattools uses g++ -B../../ to link, which fails because g++ 8 does not
understand the %@ specs.  We really shouldn't be mixing up the preinstalled
compiler with the just-built one IMHO: it should be either g++, or ../../xg++
-B../../ (probably with additional flags to find libstdc++, if that's needed)

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #42 from Tamar Christina  ---
Author: tnfchris
Date: Fri Nov  2 15:27:30 2018
New Revision: 265749

URL: https://gcc.gnu.org/viewcvs?rev=265749=gcc=rev
Log:
Fix mingw-w64 Ada native bootstrap (PR81878).

Due to the changes in PR81878 builds of GCC8 and trunk are impossible
with Ada enabled[1][2].

The reason the patch breaks the bootstrap is due to how gnatlink receives it's
arguments.

gnatlink is usually invoked as

$(GNATLINK) -v gnatcmd -o ../../gnat$(exeext) \
  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)" $(TOOLS_LIBS)

so it passes $(CC) and $(GCC_LINK) as quoted arguments to the program.
Because of this quotation the msys2 shell does not translate any paths in
$(CC) and $(GCC_LINK) from their Unix version to their Windows version.

Furthermore because there are multiple paths in the values separated by space
and because the paths often contain a prefix like -L (e.g. -L/f/foo) we can't
use `fix_srcfile_path` to fix this.

An alternative solution would have been to create a stub program that echos the
commandline options it receives back, and calling this program with $(CC) and
$(GCC_LINK)
unquoted to get them translated.  However this was a bit more invasive.

So instead for native compilations we add -B../../ such that it picks up the
lto plugin
from the previous built compiler.  Since it's native there shouldn't be a
mismatch here.

[1] https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
[2] https://gcc.gnu.org/ml/gcc/2018-07/msg00410.html

gnattools/ChangeLog:

2018-11-02  Tamar Christina  

Backport from mainline
2018-10-29  Tamar Christina  

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.


Modified:
branches/gcc-8-branch/gnattools/ChangeLog
branches/gcc-8-branch/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #40 from Tamar Christina  ---
> In most practical cases -B../../ is just redundant with $(CXX).  It's only 
> when you configure like Richard that you may run into issues, but then we can 
> assume that we're on Linux so the paths are OK I think.

Ah ok, I'll update to trunk and run a bootstrap today then and submit a patch
tomorrow. Thanks!

--- Comment #41 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct 29 09:45:50 2018
New Revision: 265583

URL: https://gcc.gnu.org/viewcvs?rev=265583=gcc=rev
Log:
Fix mingw-w64 Ada native bootstrap (PR81878).

Due to the changes in PR81878 builds of GCC8 and trunk are impossible
with Ada enabled[1][2].

The reason the patch breaks the bootstrap is due to how gnatlink receives it's
arguments.

gnatlink is usually invoked as

$(GNATLINK) -v gnatcmd -o ../../gnat$(exeext) \
  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)" $(TOOLS_LIBS)

so it passes $(CC) and $(GCC_LINK) as quoted arguments to the program.
Because of this quotation the msys2 shell does not translate any paths in
$(CC) and $(GCC_LINK) from their Unix version to their Windows version.

Furthermore because there are multiple paths in the values separated by space
and because the paths often contain a prefix like -L (e.g. -L/f/foo) we can't
use `fix_srcfile_path` to fix this.

An alternative solution would have been to create a stub program that echos the
commandline options it receives back, and calling this program with $(CC) and
$(GCC_LINK)
unquoted to get them translated.  However this was a bit more invasive.

So instead for native compilations we add -B../../ such that it picks up the
lto plugin
from the previous built compiler.  Since it's native there shouldn't be a
mismatch here.

[1] https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
[2] https://gcc.gnu.org/ml/gcc/2018-07/msg00410.html

gnattools/ChangeLog:

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.


Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #39 from Eric Botcazou  ---
> Thinking about this and what Richard said before, If we go with that
> approach the  Include directories, Library paths etc will all be wrong.
> It'll work but it's going to use a mix of the host and target compiler
> includes/libs (because all -I and -L seem to be absolute paths).  Isn't this
> potentially dangerous? could end up with an ABI issue.

In most practical cases -B../../ is just redundant with $(CXX).  It's only when
you configure like Richard that you may run into issues, but then we can assume
that we're on Linux so the paths are OK I think.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #38 from Tamar Christina  ---
> Probably not much.  So let's go with your kludge from comment #19 but with a 
> comment giving the rationale for putting it in.

Thinking about this and what Richard said before, If we go with that approach
the  Include directories, Library paths etc will all be wrong. It'll work but
it's going to use a mix of the host and target compiler includes/libs (because
all -I and -L seem to be absolute paths).  Isn't this potentially dangerous?
could end up with an ABI issue.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #37 from Eric Botcazou  ---
> Would this be a better approach?

Probably not much.  So let's go with your kludge from comment #19 but with a
comment giving the rationale for putting it in.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #36 from Tamar Christina  ---
> That seems like a big hammer though and I'm not sure other Ada maintainers
> will really be thrilled with it...  Can't we devise a kludge in the gnattools 
> dir?
> IMO it would have a far better chance of being accepted than this.

You mean the use of translate_paths? So the problem is that if we look at

GCC_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES) $(LDFLAGS)

Most of the paths come from $(CXX) which is normally fine as you'd use
$(CXX) normally as a command, e.g. $(CXX) .

When you do this the same thing happens, xgcc is a native program so it's paths
get translated.  You have `fix_srcfile_path` that can translate a single path,
but this
won't recognize multiple paths in a string, or paths to options, such as
-L, so even
splitting GCC_LINK by spaces and iterating over them calling fix_srcfile_path
won't work.

One way to fix this without needing any second program is to change how
gnatlink consumes arguments,
e.g. instead of --LINK="" use --LINK  -- or similar. E.g. an
explicit start and end marker so
the options don't have to be quoted. (same for --GCC).  This would also have
the side benefit of allowing
support for paths with spaces in them since you can now quote "" individual
paths.

Would this be a better approach?

Or did you mean make translate_paths and put it in the "tools" folder when
../stamp-tools is created?
That would probably work too.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #35 from Eric Botcazou  ---
> Sorry for the delay getting back to you Eric.

No problem.

> So the workaround I have is basically to have a dummy program
> `translate_paths.c` which just prints back all arguments it receives in argv
> (besides the program name).
> 
> This when compiled with the host compiler which is a native GCC will cause
> the msys2 runtime to translate the paths when they're passed to it (it
> doesn't do this for gnatlink because of the quotes around the arguments).

That seems like a big hammer though and I'm not sure other Ada maintainers will
really be thrilled with it...  Can't we devise a kludge in the gnattools dir?
IMO it would have a far better chance of being accepted than this.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #34 from Tamar Christina  ---
Sorry for the delay getting back to you Eric.

So the workaround I have is basically to have a dummy program
`translate_paths.c` which just prints back all arguments it receives in argv
(besides the program name).

This when compiled with the host compiler which is a native GCC will cause the
msys2 runtime to translate the paths when they're passed to it (it doesn't do
this for gnatlink because of the quotes around the arguments).

So if GCC_LINK then becomes something like

GCC_LINK_RAW=$(CXX) $(GCC_LINK_FLAGS) $(LDFLAGS)
GCC_LINK=$(shell $(translate_paths) $(GCC_LINK_RAW))

it'll translate the paths before storing them and all is well

The problem I have is where to put the compilation of translate_paths.

There are plenty of usages of GCC_LINK so ideally this should be one of the
first things done in the file. I tried putting it under the "Makefile" target
but that didn't trigger any compilation.

Maybe configure is a better place? Any suggestions?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #33 from Tamar Christina  ---
> Do you know whether it would be possible to force the conversion by applying 
> some trick to GCC_LINK in ada/gcc-interface/Makefile.in?

Yeah usually, cygpath -w would convert a path, seems we alias that to
`fix_srcfile_path` in the gcc build system and use that often. I don't think
that works in this case because the string contains more than just a path.

But I think I may have a workaround, I'll give it a try tonight once I'm back
at the Windows machine.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #32 from Eric Botcazou  ---
> Full build log is here
> https://mistuke.blob.core.windows.net/binaries/logs/build.log

Thanks.

> It may be the quoting around the options for --LINK that's causing the shell
> not to convert the paths. The unquoted ones are fine.

Do you know whether it would be possible to force the conversion by applying
some trick to GCC_LINK in ada/gcc-interface/Makefile.in?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #31 from Tamar Christina  ---
> It seems that some paths are properly translated though, for example the 
> library paths.  Do you know why?  It would be nice to have the gnatlink 
> command line that gave rise to the invocation quoted in the dump screen.

Full build log is here
https://mistuke.blob.core.windows.net/binaries/logs/build.log

from that it looks like the command preceding it is

../../gnatbind -I../rts -I.
-IE:/msys64-2.6.0/home/Tamar/MINGW-packages/mingw-w64-gcc/src/gcc-8.2.0/gcc/ada
-I- -I../rts -I.
-IE:/msys64-2.6.0/home/Tamar/MINGW-packages/mingw-w64-gcc/src/gcc-8.2.0/gcc/ada
-static -x -x
E:\msys64-2.6.0\home\Tamar\MINGW-packages\mingw-w64-gcc\src\build-x86_64-w64-mingw32\gcc\ada\tools\gnatclean.ali^M
../../gnatlink -v gnatcmd -o ../../gnat.exe \
  --GCC="../../xgcc -B../../ -I- -I../rts -I.
-I/home/Tamar/MINGW-packages/mingw-w64-gcc/src/gcc-8.2.0/gcc/ada"
--LINK="/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/./gcc/xg++
-B/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/./gcc/
-nostdinc++ -nostdinc++
-I/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/Tamar/MINGW-packages/mingw-w64-gcc/src/gcc-8.2.0/libstdc++-v3/libsupc++
-I/home/Tamar/MINGW-packages/mingw-w64-gcc/src/gcc-8.2.0/libstdc++-v3/include/backward
-I/home/Tamar/MINGW-packages/mingw-w64-gcc/src/gcc-8.2.0/libstdc++-v3/testsuite/util
-L/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-B/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-B/home/Tamar/MINGW-packages/mingw-w64-gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include-static-libstdc++ -static-libgcc
-static-libstdc++ -static-libgcc " ../link.o ../targext.o ../../ggc-none.o
../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
../rts/libgnat.a  /mingw64/lib/libiconv.a
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a  
-no-pie

It may be the quoting around the options for --LINK that's causing the shell
not to convert the paths. The unquoted ones are fine.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #30 from Tamar Christina  ---
I've started a new bootstrap without my previous changes to get the log.
I'll post the command once that finishes.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #29 from Eric Botcazou  ---
> gnatlink is _never_ a shell script though but, yes, it's apparently the
> usual mess with Unix paths on Windows.

It seems that some paths are properly translated though, for example the
library paths.  Do you know why?  It would be nice to have the gnatlink command
line that gave rise to the invocation quoted in the dump screen.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #28 from Eric Botcazou  ---
> Aaahh Yes, and now I understand what the problem is.. as
> https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408660810
> points out, gnatlink is a shell script on non-Windows but on Windows it's a
> program.  this means it's interpreting the unix paths incorrectly `/home` is
> then interpreted by the Windows API. I hadn't understood the comment fully
> until now that I knew how it's supposed to work...

gnatlink is _never_ a shell script though but, yes, it's apparently the usual
mess with Unix paths on Windows.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #27 from Tamar Christina  ---

> Yes, the expected -B flag is present in the screen dump right after 
> -Wl,--stack.
> Are you positive that your change in comment #19 eliminates the problem?

Aaahh Yes, and now I understand what the problem is.. as
https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408660810
points out, gnatlink is a shell script on non-Windows but on Windows it's a
program.  this means it's interpreting the unix paths incorrectly `/home` is
then interpreted by the Windows API. I hadn't understood the comment fully
until now that I knew how it's supposed to work...

The `../..` works because that's a valid path for both.. Not sure why gnatlink
isn't a shell script on Windows too..

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #26 from Eric Botcazou  ---
> Which does indeed show that during the bootstrap -B to the right directory
> is passed, and that the file is there.  So not sure why it's saying it can't
> find it.  If that's the case that the paths are all correct, I'll go look
> into why it's giving a file not found while the file is there.

Yes, the expected -B flag is present in the screen dump right after
-Wl,--stack.
Are you positive that your change in comment #19 eliminates the problem?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #25 from Tamar Christina  ---
>> This change broke the mingw-w64 GCC 8 bootstrap on Windows. The cleanup
>> seems a bit too aggressive as now `-B ../..` is never passed down to xg++.
>
> That shouldn't happen though, see comment #16.

The error one of the users reported is
https://user-images.githubusercontent.com/216319/40851484-dbb095da-65c7-11e8-9b98-94ca80ab2b23.png

Which does indeed show that during the bootstrap -B to the right directory is
passed, and that the file is there.  So not sure why it's saying it can't find
it.  If that's the case that the paths are all correct, I'll go look into why
it's giving a file not found while the file is there.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #24 from Eric Botcazou  ---
> This change broke the mingw-w64 GCC 8 bootstrap on Windows. The cleanup
> seems a bit too aggressive as now `-B ../..` is never passed down to xg++.

That shouldn't happen though, see comment #16.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #23 from Tamar Christina  ---
> > Hmm, I see what you mean. Currently though CXX is unable to find the
> > lto plugin.  It's somewhat confusing that CC is set to target and CXX
> > is host (but reading back on the ticket you pointed that out as well).
> 
> CXX should find the hosts LTO plugin but that should never be necessary
> because we do not use the host-compiler to LTO.  So maybe _that's_ the
> issue - that we use -flto or that we end up linking objects with LTO bytecode.
> 

Ah, I didn't know this. I'll go and try to track down the reason it's trying to
use -fuse-linker-plugin then which is likely the problem. Thanks!

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #22 from rguenther at suse dot de  ---
On Mon, 24 Sep 2018, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
> 
> --- Comment #21 from Tamar Christina  ---
> Hmm, I see what you mean. Currently though CXX is unable to find the lto
> plugin.  It's somewhat confusing that CC is set to target and CXX is host (but
> reading back on the ticket you pointed that out as well).

CXX should find the hosts LTO plugin but that should never be necessary
because we do not use the host-compiler to LTO.  So maybe _that's_ the
issue - that we use -flto or that we end up linking objects with LTO
bytecode.

And yes, the Ada boostrap setup is quite "wrecked" and doesn't properly
separate host tools from built ones :/

> So I guess the question is why does CXX not contain all options to find it's
> plugins and why does this work on Linux.
> 
> Do you happen to know where CXX is set?

CXX is set by the toplevel configure - it's the host compiler (which may
be not GCC)

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #21 from Tamar Christina  ---
Hmm, I see what you mean. Currently though CXX is unable to find the lto
plugin.  It's somewhat confusing that CC is set to target and CXX is host (but
reading back on the ticket you pointed that out as well).

So I guess the question is why does CXX not contain all options to find it's
plugins and why does this work on Linux.

Do you happen to know where CXX is set?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #20 from rguenther at suse dot de  ---
On Mon, 24 Sep 2018, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
> 
> Tamar Christina  changed:
> 
>What|Removed |Added
> 
>  CC||tnfchris at gcc dot gnu.org
> 
> --- Comment #19 from Tamar Christina  ---
> This change broke the mingw-w64 GCC 8 bootstrap on Windows. The cleanup seems 
> a
> bit too aggressive as now `-B ../..` is never passed down to xg++.
> 
> See https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
> and https://gcc.gnu.org/ml/gcc/2018-07/msg00410.html
> 
> Any objections to reverting that part of the change?
> So changing it back to
> 
> --- a/gnattools/Makefile.in
> +++ b/gnattools/Makefile.in
> @@ -72,7 +72,7 @@ ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdir)/ada
>  # Variables for gnattools, native
>  TOOLS_FLAGS_TO_PASS_NATIVE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=$(CXX)" \
> +   "CXX=$(CXX) -B../../" \
> "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> @@ -90,7 +90,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
>  # Variables for regnattools
>  TOOLS_FLAGS_TO_PASS_RE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=$(CXX)" \
> +   "CXX=$(CXX) -B../../" \
> "CFLAGS=$(CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \

But that doesn't make much sense (host driver but "target" cc1plus)

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #19 from Tamar Christina  ---
This change broke the mingw-w64 GCC 8 bootstrap on Windows. The cleanup seems a
bit too aggressive as now `-B ../..` is never passed down to xg++.

See https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
and https://gcc.gnu.org/ml/gcc/2018-07/msg00410.html

Any objections to reverting that part of the change?
So changing it back to

--- a/gnattools/Makefile.in
+++ b/gnattools/Makefile.in
@@ -72,7 +72,7 @@ ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdir)/ada
 # Variables for gnattools, native
 TOOLS_FLAGS_TO_PASS_NATIVE= \
"CC=../../xgcc -B../../" \
-   "CXX=$(CXX)" \
+   "CXX=$(CXX) -B../../" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \
@@ -90,7 +90,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
 # Variables for regnattools
 TOOLS_FLAGS_TO_PASS_RE= \
"CC=../../xgcc -B../../" \
-   "CXX=$(CXX)" \
+   "CXX=$(CXX) -B../../" \
"CFLAGS=$(CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #18 from Eric Botcazou  ---
> all-gnattools: configure-gnattools
> @: $(MAKE); $(unstage)
> @r=`${PWD_COMMAND}`; export r; \
> s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
> $(HOST_EXPORTS)  \
> (cd $(HOST_SUBDIR)/gnattools && \
>   $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
> $(STAGE1_FLAGS_TO_PASS)  \
> $(TARGET-gnattools))
> 
> so it builds for the host.  But when bootstrapping we want to build it
> similar to if it were a target library, that is, with the just built GCC.

Yes, that's what happens, i.e. the CXX passed to gnattools is CXX_FOR_TARGET.

> So,
> 
> host_modules= { module= gnattools; };
> 
> is technically not correct.  Not sure how it works during bootstrap, I'd have
> expected that the host compiler is used as well (gnattools is not 
> bootstrapped).

This would simply break, because the gnattools really need to be bootstrapped
as they generally cannot be built by the host compiler.  Quite puzzling indeed.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #17 from Richard Biener  ---
(In reply to Eric Botcazou from comment #16)
> This also breaks 'make all-gnattools' in a bootstrap build:
> 
> g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I.
> -I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc  -DIN_GCC  -g
> -O2 -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o
> aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o
> debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o
> fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o
> i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o make_util.o namet.o
> nlists.o opt.o osint.o osint-m.o output.o restrict.o rident.o s-exctab.o
> s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o
> s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o
> snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o
> switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o
> urealp.o usage.o widechar.o  ../link.o ../targext.o ../../ggc-none.o
> ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
> ../rts/libgnat.a   ../../../libbacktrace/.libs/libbacktrace.a
> ../../../libiberty/libiberty.a   -no-pie -ldl
> g++: error: unrecognized command line option ‘-no-pie’
> ../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed
> make[2]: *** [../../gnatmake] Error 1
> make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools'
> Makefile:188: recipe for target 'gnattools-native' failed
> make[1]: *** [gnattools-native] Error 2
> make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools'
> Makefile:13917: recipe for target 'all-gnattools' failed
> make: *** [all-gnattools] Error 2
> 
> During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++
> -B/home/eric/build/gcc/native/./gcc/ so this still works.

Hmm, all-gnattools does

all-gnattools: configure-gnattools
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS)  \
(cd $(HOST_SUBDIR)/gnattools && \
  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
$(STAGE1_FLAGS_TO_PASS)  \
$(TARGET-gnattools))

so it builds for the host.  But when bootstrapping we want to build it
similar to if it were a target library, that is, with the just built GCC.
So,

host_modules= { module= gnattools; };

is technically not correct.  Not sure how it works during bootstrap, I'd have
expected that the host compiler is used as well (gnattools is not
bootstrapped).

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #16 from Eric Botcazou  ---
This also breaks 'make all-gnattools' in a bootstrap build:

g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I.
-I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc  -DIN_GCC  -g -O2
-W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o
s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o
einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o
fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o
lib.o make.o makeusg.o make_util.o namet.o nlists.o opt.o osint.o osint-m.o
output.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o
scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o
sinfo.o sinput.o sinput-c.o snames.o stand.o stringt.o styleg.o stylesw.o
system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o
types.o uintp.o uname.o urealp.o usage.o widechar.o  ../link.o ../targext.o
../../ggc-none.o ../../libcommon-target.a ../../libcommon.a
../../../libcpp/libcpp.a ../rts/libgnat.a  
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a  
-no-pie -ldl
g++: error: unrecognized command line option ‘-no-pie’
../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed
make[2]: *** [../../gnatmake] Error 1
make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools'
Makefile:188: recipe for target 'gnattools-native' failed
make[1]: *** [gnattools-native] Error 2
make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools'
Makefile:13917: recipe for target 'all-gnattools' failed
make: *** [all-gnattools] Error 2

During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++
-B/home/eric/build/gcc/native/./gcc/ so this still works.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #15 from Alexandre Oliva  ---
FWIW, this patch breaks at least non-bootstrap builds when CXX is set to
"ccache g++".  gnatlink attempts to insert various gnat flags between ccache
and g++, and that fails.  Before the patch, it would work because the CXX
passed to gnattools would always start with ../../xg++.  I agree the change is
right, though, and I'm not sure what to recommend other than not using ccache,
or using it in the symlink mode, when building ada in non-bootstrap mode.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #14 from Aldy Hernandez  ---
Author: aldyh
Date: Wed Sep 13 17:06:07 2017
New Revision: 252466

URL: https://gcc.gnu.org/viewcvs?rev=252466=gcc=rev
Log:
2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
branches/range-gen2/gnattools/ChangeLog
branches/range-gen2/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 17 13:39:58 2017
New Revision: 251150

URL: https://gcc.gnu.org/viewcvs?rev=251150=gcc=rev
Log:
2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #11 from Eric Botcazou  ---
> ===
> --- Makefile.in (revision 251140)
> +++ Makefile.in (working copy)
> @@ -78,7 +78,7 @@ CXX_LFLAGS = \
>  # Variables for gnattools, native
>  TOOLS_FLAGS_TO_PASS_NATIVE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
> +   "CXX=$(CXX)" \
> "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> @@ -96,7 +96,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
>  # Variables for regnattools
>  TOOLS_FLAGS_TO_PASS_RE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
> +   "CXX=$(CXX)" \
> "CFLAGS=$(CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> 
> seems to work for me, both bootstrap and --disable-bootstrap.

The patch is OK with me if you remove CXX_LFLAGS too.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #10 from Richard Biener  ---
Created attachment 41996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41996=edit
patch for the missed optimization

Testing this to address the missed optimization(s).  This happens to fix the
testcase as expected but the underlying issue is still present.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #9 from Richard Biener  ---
Index: Makefile.in
===
--- Makefile.in (revision 251140)
+++ Makefile.in (working copy)
@@ -78,7 +78,7 @@ CXX_LFLAGS = \
 # Variables for gnattools, native
 TOOLS_FLAGS_TO_PASS_NATIVE= \
"CC=../../xgcc -B../../" \
-   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
+   "CXX=$(CXX)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \
@@ -96,7 +96,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
 # Variables for regnattools
 TOOLS_FLAGS_TO_PASS_RE= \
"CC=../../xgcc -B../../" \
-   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
+   "CXX=$(CXX)" \
"CFLAGS=$(CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \

seems to work for me, both bootstrap and --disable-bootstrap.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #8 from Eric Botcazou  ---
> As can be seen in the result:
> 
> make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
> gcc -c -g -O2 -W -Wall  -gnatpg -gnata -I- -I../rts -I.
> -I/tmp/trunk2/gcc/ada ../rts/s-casuti.adb -o s-casuti.o
> s-casuti.adb:32:08: warning: unrecognized pragma "Compiler_Unit_Warning"
> s-casuti.ads:40:08: warning: unrecognized pragma "Compiler_Unit_Warning"
> ../gcc-interface/Makefile:296: recipe for target 's-casuti.o' failed
> make[3]: *** [s-casuti.o] Error 1
> 
> so the host ada compiler (gnat 4.8) doesn't work for this part.  With
> cross-compiling we require a host compiler matching the target one, right?

Right, the tools always require a matching compiler, i.e. need a bootstrap.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #7 from Richard Biener  ---
Ah, it works when leaving CC alone and only changing CXX.  Somewhat
inconsistent I guess.  Let me try if bootstrap also still works.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> (In reply to Eric Botcazou from comment #3)
> > > I see.  I suppose it should use the build tools if not bootstrapping as 
> > > well
> > > (and/or for stage1).  Isn't this all set up correctly from the toplevel 
> > > make
> > > anyway?!
> > 
> > Do you mean that passing $(CXX) as in the cross case should work?
> 
> I would think so.  No other host library/tool dir does this kind of dance.
>
> Of course ada toplevel stuff is somewhat special...

As can be seen in the result:

make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
gcc -c -g -O2 -W -Wall  -gnatpg -gnata -I- -I../rts -I. -I/tmp/trunk2/gcc/ada
../rts/s-casuti.adb -o s-casuti.o
s-casuti.adb:32:08: warning: unrecognized pragma "Compiler_Unit_Warning"
s-casuti.ads:40:08: warning: unrecognized pragma "Compiler_Unit_Warning"
../gcc-interface/Makefile:296: recipe for target 's-casuti.o' failed
make[3]: *** [s-casuti.o] Error 1

so the host ada compiler (gnat 4.8) doesn't work for this part.  With
cross-compiling we require a host compiler matching the target one, right?

> > > So I guess generally enabling C++ when enabling Ada would regress cross
> > > builds.
> > 
> > Yes, we would need to enable it only for native.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #5 from Richard Biener  ---
(In reply to Eric Botcazou from comment #3)
> > I see.  I suppose it should use the build tools if not bootstrapping as well
> > (and/or for stage1).  Isn't this all set up correctly from the toplevel make
> > anyway?!
> 
> Do you mean that passing $(CXX) as in the cross case should work?

I would think so.  No other host library/tool dir does this kind of dance.

Of course ada toplevel stuff is somewhat special...

> > So I guess generally enabling C++ when enabling Ada would regress cross
> > builds.
> 
> Yes, we would need to enable it only for native.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

--- Comment #4 from Richard Biener  ---
Btw, it looks even wrong -- the host C++ compiler built some of the objects in
the failing link (libcpp.a).  So xg++ might end up linking the wrong
standard library (try building with clang++ and libc++?)

../../xg++ -B../../ -B../../../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B../../../x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-L../../../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L../../../x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -static-libstdc++
-static-libgcc -I- -I../rts -I. -I/tmp/trunk2/gcc/ada -static-libstdc++
-static-libgcc  -DIN_GCC  -g -O2 -W -Wall -o ../../gnatmake b_gnatm.o
a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o
butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o
err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o
interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o
mlib-fil.o mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o
nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o
prj-com.o prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o
prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o
restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o
sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o
sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o
system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o
types.o uintp.o uname.o urealp.o usage.o widechar.o  ../link.o ../targext.o
../../ggc-none.o ../../libcommon-target.a ../../libcommon.a
../../../libcpp/libcpp.a ../rts/libgnat.a  
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a   
-ldl
make[3]: ../../xg++: Command not found
../gcc-interface/Makefile:2647: recipe for target '../../gnatmake' failed
make[3]: *** [../../gnatmake] Error 127

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
> I see.  I suppose it should use the build tools if not bootstrapping as well
> (and/or for stage1).  Isn't this all set up correctly from the toplevel make
> anyway?!

Do you mean that passing $(CXX) as in the cross case should work?

> So I guess generally enabling C++ when enabling Ada would regress cross
> builds.

Yes, we would need to enable it only for native.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878

Richard Biener  changed:

   What|Removed |Added

Summary|--disable-bootstrap |--disable-bootstrap
   |--enable-languages=c,ada|--enable-languages=ada
   |fails   |fails

--- Comment #2 from Richard Biener  ---
I see.  I suppose it should use the build tools if not bootstrapping as well
(and/or for stage1).  Isn't this all set up correctly from the toplevel make
anyway?!

So I guess generally enabling C++ when enabling Ada would regress cross builds.