https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777
--- Comment #11 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to Vincent Lefèvre from comment #10) > (In reply to Jakub Jelinek from comment #9) > > That is not true, automake is highly customizable, you can e.g. override > > COMPILE/LTCOMPILE variables in Makefile.am or something similar. > > The issue is that what COMPILE/LTCOMPILE should contain is not specified, so > that it is impossible to write a replacement that will be guaranteed to work > in a portable way. > > For instance, the following is generated: > > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \ > $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \ > $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ > $(AM_CFLAGS) $(CFLAGS) > > but the AM_V_lt variable is nowhere documented. Thus replacing > COMPILE/LTCOMPILE would require the developer to use obscure internals. I > will never do that! > > Anyway, this would not be these variables that one would need to change, but > the Make rules that invoke the compiler, like: > > .c.o: > $(AM_V_CC)depbase=`echo $@ | sed > 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\ > $(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\ > $(am__mv) $$depbase.Tpo $$depbase.Po > # $(AM_V_CC)source='$<' object='$@' libtool=no \ > # DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \ > # $(AM_V_CC_no)$(COMPILE) -c -o $@ $< > > But this is even worse: more internals, more code that is > platform-dependent... The lack of specification/documentation sounds more like a bug with automake/libtool than with anything under GCC's control. I'd suggest reporting the issue to automake/libtool instead, but they're not exactly very actively maintained these days, so... YMMV.
