PATCH: LDFLAGS handling in V3

[Daniel Jacobowitz]

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'.

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

> 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.

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC