https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492
--- Comment #13 from simon at pushface dot org --- (In reply to Luke A. Guest from comment #2) > But, I noticed this in the gnat makefile a while back and was going to > investigate, but haven't got around to it yet: > > # *-elf, *-eabi, or *-eabispe > ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),) > TOOLS_TARGET_PAIRS=\ > mlib-tgt-specific.adb<mlib-tgt-specific-xi.adb \ > indepsw.adb<indepsw-gnu.adb > endif > > Essentially, we just need for that to include a specific system or build > with just those two files and it's sorted. 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. If it is the case that any arm-*-eabi target is going to be a bare runtime 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 map feature yet. 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.
