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