From: Mark Mitchell <mark@codesourcery.com>
To: Rask Ingemann Lambertsen <rask@sygehus.dk>
Cc: Bernd Schmidt <bernds_cb1@t-online.de>,
Jie Zhang <jzhang918@gmail.com>,
gcc@gcc.gnu.org, GCC Patches <gcc-patches@gcc.gnu.org>,
rsandifo@nildram.co.uk, hp@gcc.gnu.org
Subject: Re: Link tests after GCC_NO_EXECUTABLES
Date: Fri, 30 Nov 2007 11:41:00 -0000 [thread overview]
Message-ID: <474F8E96.8000605@codesourcery.com> (raw)
In-Reply-To: <20071130022132.GL17368@sygehus.dk>
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
next prev parent reply other threads:[~2007-11-30 4:16 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <46EFBCC1.6070200@gmail.com>
[not found] ` <46EFC383.7020503@t-online.de>
[not found] ` <46EFC9E9.7090201@gmail.com>
[not found] ` <46EFCEF9.3060304@t-online.de>
[not found] ` <46EFCF7A.2080704@gmail.com>
[not found] ` <46EFD236.6080907@t-online.de>
[not found] ` <46EFDA4D.3070006@gmail.com>
2007-11-27 15:35 ` Bernd Schmidt
2007-11-27 22:17 ` Mark Mitchell
2007-11-27 22:40 ` Bernd Schmidt
2007-11-27 22:43 ` Mark Mitchell
2007-11-27 22:58 ` Bernd Schmidt
2007-11-27 23:17 ` Mark Mitchell
2007-11-28 0:23 ` Bernd Schmidt
2007-11-28 0:33 ` Mark Mitchell
2007-11-28 1:03 ` Bernd Schmidt
2007-11-28 1:24 ` Mark Mitchell
2007-11-28 6:34 ` Bernd Schmidt
2007-11-28 10:37 ` Mark Mitchell
2007-11-28 15:47 ` Bernd Schmidt
2007-11-28 8:16 ` Joseph S. Myers
2007-11-28 10:01 ` Mark Mitchell
2007-11-28 11:37 ` Joseph S. Myers
2007-11-28 11:40 ` Mark Mitchell
2007-11-28 15:37 ` Bernd Schmidt
2007-11-28 13:07 ` Richard Sandiford
2007-11-28 16:06 ` Rask Ingemann Lambertsen
2007-11-28 16:59 ` Daniel Jacobowitz
2007-11-28 18:55 ` Mark Mitchell
2007-11-28 22:41 ` Richard Sandiford
2007-11-28 23:03 ` Rask Ingemann Lambertsen
2007-11-29 6:21 ` Mark Mitchell
2007-11-30 21:07 ` Rask Ingemann Lambertsen
2007-11-30 21:08 ` Mark Mitchell
[not found] ` <20071130211005.GQ17368@sygehus.dk>
2007-12-01 9:48 ` Richard Sandiford
2007-12-01 11:53 ` Rask Ingemann Lambertsen
2007-12-01 12:03 ` Rask Ingemann Lambertsen
2007-12-01 13:37 ` Andreas Schwab
2007-12-01 22:35 ` Rask Ingemann Lambertsen
2007-12-02 21:11 ` Mark Mitchell
2007-12-05 17:22 ` Rask Ingemann Lambertsen
2007-12-06 0:38 ` Mark Mitchell
2007-12-06 17:58 ` Rask Ingemann Lambertsen
2007-12-07 1:37 ` Mark Mitchell
2007-12-07 15:31 ` Rask Ingemann Lambertsen
2007-12-07 18:39 ` Mark Mitchell
2007-12-07 21:48 ` Rask Ingemann Lambertsen
2007-12-07 21:57 ` Mark Mitchell
2007-12-13 22:25 ` [PATCH v2] " Rask Ingemann Lambertsen
2007-12-30 13:46 ` Ping " Rask Ingemann Lambertsen
2007-12-30 17:41 ` Paolo Bonzini
2007-12-07 11:27 ` Richard Sandiford
2007-12-07 15:18 ` Rask Ingemann Lambertsen
2007-12-08 11:25 ` Richard Sandiford
2007-12-04 14:46 ` Rask Ingemann Lambertsen
2007-12-05 0:10 ` Hans-Peter Nilsson
2007-12-05 0:19 ` Rask Ingemann Lambertsen
2007-12-05 0:46 ` Hans-Peter Nilsson
2007-11-30 3:56 ` Richard Sandiford
2007-11-30 5:32 ` Mark Mitchell
2007-11-30 8:07 ` Benjamin Kosnik
2007-11-30 9:58 ` Rask Ingemann Lambertsen
2007-11-30 11:41 ` Mark Mitchell [this message]
2007-11-30 23:25 ` Rask Ingemann Lambertsen
2007-11-30 13:16 ` Richard Sandiford
2007-11-30 20:32 ` Rask Ingemann Lambertsen
2007-11-30 21:10 ` Mark Mitchell
2007-11-30 21:15 ` DJ Delorie
2007-12-01 9:55 ` Richard Sandiford
2007-12-02 21:01 ` Mark Mitchell
2007-12-03 15:55 ` Richard Sandiford
2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson
2007-12-03 16:07 ` Richard Sandiford
2007-12-03 22:43 ` Hans-Peter Nilsson
2007-12-03 16:59 ` Geoff Keating
2007-12-03 22:39 ` Hans-Peter Nilsson
2007-12-04 6:52 ` Geoff Keating
2007-12-04 22:26 ` btest-gcc.sh patch ping Hans-Peter Nilsson
2009-03-28 14:10 ` btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES Richard Guenther
2009-03-28 20:37 ` Geoff Keating
2007-11-30 20:49 ` Rask Ingemann Lambertsen
2008-05-15 21:40 ` Bernd Schmidt
2008-05-15 23:02 ` Richard Sandiford
2008-05-15 23:10 ` Bernd Schmidt
2008-05-16 0:18 ` Mark Mitchell
2008-05-16 2:21 ` Joseph S. Myers
2008-06-18 21:05 ` Ralf Wildenhues
2008-06-19 3:57 ` Mark Mitchell
2008-07-07 20:14 ` Ralf Wildenhues
2007-11-28 8:54 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474F8E96.8000605@codesourcery.com \
--to=mark@codesourcery.com \
--cc=bernds_cb1@t-online.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=hp@gcc.gnu.org \
--cc=jzhang918@gmail.com \
--cc=rask@sygehus.dk \
--cc=rsandifo@nildram.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).