PATCH: LDFLAGS handling in V3

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Wed, Jul 27, 2005 at 02:56:25PM -0700, Mark Mitchell wrote:
> 
>>Daniel Jacobowitz wrote:
>>
>>
>>>That would be a bug.  LDFLAGS are intended to be compiler driver
>>>options; that's not a new requirement.
>>
>>OK, great.  So, then, the libstdc++ Makefiles should turn them into -Wc, 
>>options to libtool, rather than -Wl, as I proposed?  That would make 
>>clear to libtool that it needs to pass them along to the compiler, 
>>rather than silently ignore them.  Thoughts?
> 
> Or you could do that in the top level, since only --sysroot is affected?

Do we also assume that all target libraries use libtool?  If not, it's 
not safe for the toplevel to be sticking in -Wc, options.

It's not just --sysroot that's affected.  For example, -specs= is also 
ignored, even though that obviously affects linking.  So are -m options, 
even though the driver may use those to govern the set of options passed 
to the underlying linker.

(In fact, somewhat curiously, the libstdc++ Makefiles pass other options 
to libtool that it ignores.  Most of these look like they have no impact 
on linking, so perhaps this is just the libstdc++ Makefiles being funky, 
or perhaps there is some circumstance where they get used.  For example:

CXXLINK = $(LIBTOOL) --tag CXX --mode=link $(CXX) \
           $(OPT_LDFLAGS) $(SECTION_LDFLAGS) ...

where SECTION_LDFLAGS has things like -fdata-sections.  libtool does not 
pass these to the "linker", which is really xgcc.)

> Will libtool pass -Wc options to the link phase?

Empirically, yes.  (In fact, since LDFLAGS are supposed to be compiler 
options, it does exactly the right thing; it strips the -Wc, and passes 
them along.  With -Wl, it passes them along -- but with the -Wl, still 
there, so the xgcc driver doesn't see them.)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304