broken configury, testing for 'ld'
Geoff Keating
geoffk@geoffk.org
Tue Nov 28 16:01:00 GMT 2000
> Cc: libstdc++@sources.redhat.com
> From: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
> Date: 28 Nov 2000 21:18:14 -0200
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)
>
> On Nov 28, 2000, Geoff Keating <geoffk@geoffk.org> wrote:
>
> > and then passes LD_FOR_TARGET as $LD to the libstdc++ configure.
>
> If GCC has a different idea of what LD_FOR_TARGET is than what
> LD_FOR_TARGET says, then it is LD_FOR_TARGET that should be fixed.
That's what I thought first, but that's slightly tricky. The problem
is that the toplevel LD_FOR_TARGET is evaluated before GCC is built,
and GCC's rules for finding the linker are slightly arcane.
IMHO, it would be better to delete LD and LD_FOR_TARGET from the
toplevel Makefile. All this stuff should be using GCC to link anyway,
or at least to find the linker.
The problem then is that in a combined tree, we want to use ld/ld-new...
> > Is this test really supposed to be checking for the ld used by GCC?
>
> Yes but, following autoconf practice, this test (from libtool, BTW)
> lets the user override it, under the assumption that, if the user
> specifies it, s/he either knows better or s/he's overriding it on
> purpose.
OK. (I can't argue with that, since I worked around the problem by
specifying LD myself to the toplevel Makefile... :-)
--
- Geoffrey Keating <geoffk@geoffk.org>
More information about the Libstdc++
mailing list