https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492
--- Comment #14 from Luke A. Guest <laguest at archeia dot com> --- (In reply to simon from comment #13) > TOOLS_TARGET_PAIRS is set in both gnattools/Makefile (when it has been > configured) and gcc/ada/gcc-interface/Makefile.in. Your patch is to the > gnattools/ one, the gcc-interface one already has this pair. Yup, as with the patches that we've wrangling with for the past 15 years (yes, that long) that has been the case, although I don't know when it all got split up into libada and gnattools dirs. But, the gnattool/configure case was moved there from the gcc-interface/Makefile.in, I always thought that they just forgot to remove the one from there. > If it is the case that any arm-*-eabi target is going to be a bare runtime If any *-elf/eabi-elf/coff/whatever target is going to be bare runtime... When I first started looking into this I was interested in ARM, not so much now. But maybe in the future. > target, with --disable-libada disabling gnattools/, then Eric’s patch and > Arno’s incantation will IMO work - I just built GCC 5 arm-eabi with Eric’s > patch and the two files were successfully copied into build/gcc/ada/tools, > and arm-eabi-gnatmake is capable of building a library. Haven’t checked the Interesting. > map feature yet. The what? > Looking at the two versions of TOOLS_TARGET_PAIRS, it seems that > gcc-interface/Makefile is mainly concerned with building the RTS > (LIBGNAT_TARGET_PAIRS etc) with the TOOLS_TARGET_PAIRS being left in place, > pretty much as fossils, when building the tools was moved to > gnattools/Makefile. Would be nice if this was documented in an easy to understand way in the makefiles, as in "What it's there for and why." As I state above, I have been dabbling on and off for 14 years for this. I have posted about it in various places and only got the response of the incantation, which I told them never worked, shame it's taken this long to get this quite major issue fixed.
