Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell <mark at codesourcery dot com>]

Rask Ingemann Lambertsen wrote:

>> Perhaps we should turn target-libgfortran off by default for mips*-elf*.
> 
>    No. There is a point in excercising the compiler: Testing. In most cases,
> you don't find problems with the compiler until you try to compile something.

When building the compiler and its libraries, testing is of incidental
benefit; the primary goal is to build things. :-) The testsuite is for
testing things.

It's great to know that gfortran works for other ELF targets.  That
means that there must be something a bit odd in the MIPS support
somewhere, and I'm sure we can find it and fix it.

Thanks for working on the gfortran configure script.  I think it would
be great to make that work like the libstdc++ script.

>    This hunk should be left out. And I would prefer that we don't revert the
> patch until everything that builds with the patch also builds without the
> patch.

I don't think that's necessary -- unless these things built with
previous releases, in which case I'd be very concerned about making a
change that caused fewer things to build.  Did this work in 4.2?  I
don't know, but I'm expecting that it did not?

It sounds like we upgraded libtool, and that introduced link-time tests
into libstdc++, which caused build failures.  So you came up with the
top-level patch, which then probably made it possible to build some of
the other target libraries that didn't build before for bare metal
because they had always depended on link-time tests.  Is that correct?

We should be conservative about making changes in assumptions.  If we're
going to change the assumption that target library configure scripts
cannot rely on link-time tests when $with_newlib is set, then let's do
that consciously.  I think it's reasonable to take that position (even
though it's not my preference), but I don't want to change the
assumption quietly.  And, I think libstdc++ is our canonical model of a
run-time library; others should follow its lead, until/unless we
consciously decide otherwise.

I also don't want to see each architecture or run-time library doing
things in different ways.  GCC's biggest strength is its cross-platform
nature; we undermine that every time we do things in slightly different
ways within our own individual areas of concentration.

I'm in no way criticizing you or your top-level patch.  I understand
completely why you did what you did and its benefits.  But, I want to
get everyone on the same page, and until that happens, I want to stick
with how things have been in the past.

>    Additionally, I would prefer we call the option something else than
> --with-newlib - suppose there's no newlib for the target. At least the AVR
> uses something else.

That might be a good idea -- I think we do need to know which C library
is in use for at least some of the target libraries.  I'm pretty sure
that libstdc++ actually depends on --with-newlib meaning that you're
using Newlib (rather than some other C library) in that it uses
facilities in Newlib that aren't necessarily part of a standard C
library.  I could be wrong about that, though.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713