PATCH: LDFLAGS handling in V3

Mark Mitchell mark@codesourcery.com
Sun Jan 1 18:19:00 GMT 2006


>>2005-12-30  Mark Mitchell  <mark@codesourcery.com>
>>
>>	* src/Makefile.am (LTLDFLAGS): New variable.
>>	(CXXLINK): Use it.
>>	* libsupc++/Makefile.am (LLDFLAGS): New variable.
>>	(CXXLINK): Use it.
>>	* src/Makefile.in: Regenerated.
>>	* libsupc++/Makefile.in: Likewise.
> 
> 
> How can this be in the right place?  As far as I can see it will affect
> every subdirectory using libtool.  Heck, maybe the toplevel Makefile
> should handle it.

It won't affect anything which doesn't choose to use it.  Yes, it should
eventually be used by all libtool-linking Makefiles, but we can start
with libstdc++ and incrementally add it elsewhere, testing as we go.

We could set LTLDFLAGS at the toplevel, but then subdirectory Makefiles
that want to change/add to LDFLAGS might also have to reset LTLDFLAGS.
We certainly need some changes to the libstdc++/ Makefiles in order to
actually use LTLDFLAGS.

>>Index: libtool-ldflags
>>===================================================================
>>--- libtool-ldflags	(revision 0)
>>+++ libtool-ldflags	(revision 0)
>>@@ -0,0 +1,97 @@
>>+#! /bin/sh
> 
> 
>>+LTLDFLAGS = $(shell $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
> 
> You should use $(CONFIG_SHELL) here, I think?

Other commands in libstdc++/*/Makefile.in use $(SHELL).  (That may well
be set to CONFIG_SHELL by the toplevel.)  For example, from
libstdc++/Makefile.in:

$(top_builddir)/config.status: ...
        $(SHELL) ./config.status --recheck

Here, since we're assigning to a variable rather than in a rule, it
makes sense just to use the $(shell) function.  I've checked that GNU
make honors SHELL when using the $(shell) function.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(650) 331-3385 x713



More information about the Gcc-patches mailing list