Dave Korn wrote:
> Eric Botcazou wrote:
>> Your .diff contains this
>>
>> + EH_MECHANISM=-gcc
>>
>> so it looks as though the base compiler was SJLJ.
>
> Ah, bingo! Thanks Eric; yes, I have a recent build of an SJLJ Gnat from
> HEAD lying around my PATH ahead of my old 4.3.2-with-ZCX. Getting that out of
> the way should help!
And although it turns out that was the case, it didn't actually solve the
problem. It turns out to be a horribly subtle artifact of this factor:
> switched it over to ZCX, and it worked well
> enough to pass most of the testsuite, including EH. Now I'm changing the
> target pairs on top of that and suddenly it's complaining, which is why I'm
> confused; I thought that bit was stable.
This was driving me mad, I had a perfectly working ZCX compiler but every
time I tried to change anything, it mysteriously switched itself back to SJLJ
for seemingly no reason at all and then failed building target-libada as a
consequence. The thing was down to the particular way in which I was setting
the LIBGNAT_TARGET_PAIRS variable; because of the way Cygwin and MinGW share
most of their port implementation, I was doing this:
LIBGNAT_TARGET_PAIRS = \
[ ... overrides only for mingw ... ]
if ( ... target is cygwin ... )
# blank it out, no cygwin-only overrides yet
LIBGNAT_TARGET_PAIRS =
endif
LIBGNAT_TARGET_PAIRS += \
[ ... common overrides ... ]
And the result of doing it this way was that LIBGNAT_TARGET_PAIRS ended up
with an embedded leading space. This wouldn't have mattered much, except for
one little thing: later, in gcc-interface/Makefile.in, we have ...
ifeq ($(filter-out a-except%,$(LIBGNAT_TARGET_PAIRS)),$(LIBGNAT_TARGET_PAIRS))
LIBGNAT_TARGET_PAIRS += \
a-except.ads<a-except-2005.ads \
a-except.adb<a-except-2005.adb
endif
... and the $(filter-out) function has an implicit $(strip) operation, and as
a result even though the filter-out doesn't remove anything from
LIBGNAT_TARGET_PAIRS (because this is indeed supposed to be a ZCX compiler
we're building and it doesn't yet have any override for a-except.*), the
result doesn't match because the leading blank is missing. And so the
compiler would revert to SJLJ!
Is it just a bug for me to generate LIBGNAT_TARGET_PAIRS in a way that has
superfluous spaces (whether leading, trailing or embedded), or shall I send a
patch to add a $(strip) to the right-hand side of the ifeq comparison? Or
perhaps we should do
LIBGNAT_TARGET_PAIRS:=$(strip $(LIBGNAT_TARGET_PAIRS))
right at the top-level, just after the per-target chunks, to ensure the string
is properly normalised before any further tests and comparisons we might want
to make?
cheers,
DaveK
