Fallout (mostly runtime library-related) from GCC version number change (take two)

[Zack Weinberg]

Ian Lance Taylor <ian@airs.com> writes:

>>  # The version of GCC in this tree
>> -gcc_version=@gcc_version@
>> +gcc_version = $(shell cat $(srcdir)/../gcc/BASE-VER)
>
> As I may have seen you mention somewhere, this should use :=, not =.

Yes, it's becoming increasingly obvious that = was a mistake.  (Daniel
Berlin reports that this is the cause of the mysterious serialization
of gcc subdirectory builds, for instance.)

>>  # Directory in which the compiler finds libraries etc.
>> -libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
>> +libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(gcc_version)
>
> Interesting.  This looks like a change in behaviour, but the old
> behaviour does look wrong.

$(version) and $(gcc_version) were the same thing.


>> +mkheaders: mkheaders.almost $(srcdir)/../gcc/BASE-VER
>> +	sed -e 's/@gcc_version@/$(shell cat $(srcdir)/../gcc/BASE-VER)/' \
>> +		< $< > $@T
>> +	mv -f $@T $@
>
> Why not use $(gcc_version) here, rather than invoking $(shell) again?

Accident: I think the above diff went in before the previous one.

>> -install-mkheaders: stmp-int-hdrs $(STMP_FIXPROTO) install-include-dir \
>> +install-mkheaders: stmp-int-hdrs $(STMP_FIXPROTO) install-itoolsdirs \
>>    macro_list xlimits.h
>>  	for file in $(USER_H); do \
>>  	  realfile=`echo $$file | sed -e 's|.*/\([^/]*\)$$|\1|'`; \
>
> Looks like you lost the dependency on install-include-dir here.  Was
> that intentional?

Yes.  If you read the commands for that rule carefully, you'll see it
doesn't install anything in $(libsubdir)/include.

>> -tool_include_dir='$(libdir)/gcc/$(target_alias)/'${gcc_version}/include
>> +gcc_version='$(shell cat $(srcdir)/../gcc/BASE-VER)'
>> +tool_include_dir='$(libdir)/gcc/$(target_alias)/$(gcc_version)/include'
>> +AC_SUBST(gcc_version)
>>  AC_SUBST(tool_include_dir)
>
> This is going to lead to multiple evaluation of gcc_version.  automake
> is going to initialize the variables using =, so they will be
> rexpanded every time.  I would be particularly worried about the usage
> in subdirectories of libffi; I doubt srcdir will be correct.  It would
> seem safer to use top_srcdir instead.
>
> Note that there is now no reason to substitute tool_include_dir.  It
> can be determined entirely in terms of make variables, and you might
> as well copy the definition into Makefile.  Then that value could be
> set using :=, avoiding the extra evaluations.

I was leaving the definition in the configure script to avoid having
to find exactly which makefiles needed it, especially in libraries
with subdirectory makefiles.  I can change that, though.
$(top_srcdir) is a good idea when we've got it.

> I have to go now, so I won't continue any further for now.  Hopes this
> helps.

Yes, thank you.

I have to go run errands now but will be revising the patch later this
afternoon.

zw