probs cross-building current libstdc++-v3, because of need tolink?

[cgd at broadcom dot com]

Hi folks,

I've been running into problems building current gcc sources that seem
to be related to the changes:

2003-08-04  Phil Edwards  <pme@gcc.gnu.org>

        Convert to new autotools.
        [ ... ]

to the libstdc++-v3 configury.

I'm trying to build for target mipsisa64-elf, from host
i686-pc-linux-gnu, using a combined-tree build.

I've tried sources as recent as today, and my last known-good build
(posted to the test results list) was 2003-07-30 00:00UTC.  I've not
binary searched down to those changes, but rather traced through the
configury and seen that that's where they went wrong.


My host compiler is GCC 3.2.3 and lives in
prefix=/projects/bbp/sbtools/x86-linux-rh7.2/native-2.7.9
(ignore the strange numbers 8-)

There are also binutils 2.13.2.1 installed in $prefix, so that
there's a $prefix/i686-pc-linux-gnu/bin/{as,ld,...}.


It looks like what's happening is that the top-level gcc 'configure'
is detecting the linker to be $prefix/i686-pc-linux-gnu/bin/ld, and
setting LD to that.  (it's an absolute path.)

The gcc configure script sees that 'LD' is set, in the
gcc/configure.in code:

AC_MSG_CHECKING(what linker to use)
in_tree_ld=no
gcc_cv_ld=
gcc_cv_gld_major_version=
gcc_cv_gld_minor_version=
gcc_cv_ld_gld_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/ld
gcc_cv_ld_bfd_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/bfd
if test -x "$DEFAULT_LINKER"; then
        gcc_cv_ld="$DEFAULT_LINKER"
elif test -x "$LD"; then
        gcc_cv_ld="$LD"
elif test -x collect-ld$host_exeext; then
        # Build using linker in the current directory.
        gcc_cv_ld=./collect-ld$host_exeext
elif test -f $gcc_cv_ld_gld_srcdir/configure.in \
     && test -f ../ld/Makefile; then
        ...

And so therefore decides to use that and *does not* create the 'ld'
symlink to ld/ld-new.

When the libstdc++-v3 configure runs, it tries to invoke the c++
compiler to link a program, and that fails, because collect2 fails to
find 'ld' (because there's no 'ld' symlink):

configure:2335: checking for C compiler default output
configure:2338:  /home/cgd/proj/gcc-testing6/work/mipsisa64-elf.build/gcc/xgcc -B/home/cgd/proj/gcc-testing6/work/mipsisa64-elf.build/gcc/ -nostdinc -B/home/cgd/proj/gcc-testing6/work/mipsisa64-elf.build/mipsisa64-elf/newlib/ -isystem /home/cgd/proj/gcc-testing6/work/mipsisa64-elf.build/mipsisa64-elf/newlib/targ-include -isystem /home/cgd/proj/gcc-testing6/combined/newlib/libc/include -B/home/cgd/proj/gcc-testing6/work/mipsisa64-elf.install/mipsisa64-elf/bin/ -B/home/cgd/proj/gcc-testing6/work/mipsisa64-elf.install/mipsisa64-elf/lib/ -isystem /home/cgd/proj/gcc-testing6/work/mipsisa64-elf.install/mipsisa64-elf/include -isystem /home/cgd/proj/gcc-testing6/work/mipsisa64-elf.install/mipsisa64-elf/sys-include -L/home/cgd/proj/gcc-testing6/work/mipsisa64-elf.build/ld -O2 -g -O2 -O2 -g -O2  conftest.c  >&5
collect2: cannot find `ld'
configure:2341: $? = 1

(I'm not sure which new-autoconf macro causes that test to be emitted,
i don't have new-autoconf around and wanted to send this off before
too much longer...  8-)


I pulled out some old sources (2003-07-30 00:00 UTC since i know those
work), and find that in fact, 'ld' is not found there either, for the
same reason.

However, until the libstdc++-v3 configuration was changed, nothing in
libstdc++-v3 actually *required* the configure-time compile/link
checks to succeed.  (it was only testing for library features AFAICT,
and have all answered 'no' didn't actually hurt.)

Anyway, the end result is that the libstdc++-v3 configure fails.


Any idea what the Right Thing is to solve this problem?

It seems to me that the fact that the 'ld' symlink isn't created
(because 'LD' is set and since it's absolute passes "test -x") may be
a bug.

On the other hand, it's not clear that anything in the libstdc++-v3
build process should depend on being able to final-link programs.
(several reasons: "what linker flags to use?"  e.g., on mips w/
libgloss one really wants -Tsomething.ld, often.  also "can you do
that at all?"  e.g., systems like vxworks where what the user
typically produces are .o files which are dynamically loaded...)


Thoughts?


chris