PATCH: LDFLAGS handling in V3
Mark Mitchell
mark@codesourcery.com
Wed Jul 27 23:49:00 GMT 2005
Mark Mitchell wrote:
> If all target libraries are assumed to be built with libtool, then we
> can indeed defer to the user.
However, that is not the case. For example, libiberty is not built with
libtool. Empirically setting LDFLAGS_FOR_TARGET to include a -Wc,
option at the top level results in configure-target-libiberty failing,
because configure tries to actually invoke the linker with the -Wc,
option, which it doesn't understand, resulting eventually in:
checking for library containing strerror... configure: error: Link tests
are not allowed after GCC_NO_EXECUTABLES
because an earlier link command has failed.
> I do understand what you mean about quoting and about reusable scripts.
> I suppose I could work on that, once we know what we want it to do.
So, I think we have to go this route.
Therefore, I thought about writing a script which, when invoked as
"libtool-ldflags $(LDFLAGS)" outputs a string that will look like:
-Xcompiler flag1 -Xcompiler flag2
where flagN is properly quoted, so that you can do:
eval libtool --mode=link ... `libtool-ldflags $(LDFLAGS)`
(Alexandre, I didn't want to use -XCClinker because the GCC version of
libtool doesn't have that, but that's a detail.)
However, this doesn't seem like it would work well, because of the need
for "eval", which means that other options on the link line might get
mangled. In GNU-make, we could do:
LTLDFLAGS := `libtool-ldflags $(LDFLAGS)`
and then:
libtool --mode=link ... $(LTLDFLAGS)
which should work OK, since GNU make will evaluate the shell command
early. But, libstdc++ hasn't yet gone over to GNU make; it's still
assuming plain automake, I think. I don't really know how to solve this
problem in that context.
I guess the best I can think of is to have the top-level Makefile add:
"LTLDFLAGS=`libtool-ldflags $(LDFLAGS)`"
to EXTRA_TARGET_FLAGS. Then, the sub-make files can just choose between
LDFLAGS and LTLDFLAGS, depending on whether or not they're using
libtool. Does that sound like the right plan?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304
More information about the Gcc-patches
mailing list