Re: PATCH: LDFLAGS handling in V3

[Mark Mitchell <mark at codesourcery dot com>]

Daniel Jacobowitz wrote:
> On Sun, Jan 01, 2006 at 10:19:09AM -0800, Mark Mitchell wrote:
> 
>>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.
> 
> 
> I was suggesting passing a transformed LDFLAGS to the subdirectory. 
> Probably based on grepping configure.in or configure.ac for
> '^A[CM]_PROG_LIBTOOL'.

If the consensus is that this is better, we can do that.   But, how do
we know the subdirectory doesn't want the unmodified LDFLAGS for some
other purpose?  Or, do you want to just pass LTLDFLAGS to all
subdirectories?  In that case, there's no need for grepping, but we'll
still need a change to each subdirectory Makefile to use LTLDFLAGS
instead of LDFLAGS.

None of these Makefile issues were raised in the previous incaranation
of the patch.  The key part of the patch is the libtool-ldflags script.
If there's going to be controversy about how to use the script, maybe we
could start with getting the script itself checked in.

My preference is to get the current patch checked in, and then refine
the exact logic for where the script is called later.  It's not hard to
find all the uses of --mode=link in our Makefiles and adjust in one
direction or the other.

> Subdirectories which want to change/add to LDFLAGS shouldn't.  Do any?
> LDFLAGS is supposed to be for user-specified options exclusively.

libjava/Makefile.in adds to LDFLAGS for particular libraries; see
libgij_la_LDFLAGS.  In that case, it doesn't look like any -Xcompiler
quoting is necessary, and the libgcj Makefile could add -Xcompiler
itself, rather than relying on libtool-ldflags, since it knows it's
using libtool.  So, I don't have any reason to dispute your conclusion
that LDFLAGS is essentially immutable.

> No no.  GNU make will pass foo in $(shell foo) to $(SHELL) for
> evaluation.  That will cause foo to be treated as a program name and
> passed to execve.  Which means the #!/bin/sh in your script will be
> honored.  Instead, it should be $(shell $(SHELL) .../script $(LDFLAGS))
> so that $(SHELL) is used to run the shell script.

OK, consider that change made.

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