This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: LDFLAGS handling in V3
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