From: Rask Ingemann Lambertsen <rask@sygehus.dk>
To: Mark Mitchell <mark@codesourcery.com>
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
Subject: Re: Link tests after GCC_NO_EXECUTABLES
Date: Fri, 30 Nov 2007 21:07:00 -0000 [thread overview]
Message-ID: <20071130181424.GO17368@sygehus.dk> (raw)
In-Reply-To: <474DF7E4.6050308@codesourcery.com>
On Wed, Nov 28, 2007 at 03:21:08PM -0800, Mark Mitchell wrote:
> Rask Ingemann Lambertsen wrote:
>
> > Here's a detail I'm missing. If you configure --with-newlib (or get it
> > implicitly) and then link with something else when using the toolchain, then
> > the answers will be wrong, but I don't see how that's any worse than
> > assuming a set of hard coded link test results.
>
> The issue isn't just Newlib; it's the "BSP" (crt0, system-call
> implementations, etc.) that you might have in your individual system.
> Some BSPs add considerable functionality beyond that provided by Newlib
> itself, and we don't want libstdc++ to detect and rely on that.
Ok, I got that. I suppose that means you don't actually have a way of
making libstdc++ use such extra functionality?
> > How about an explicit option --without-link-tests, --disable-link-tests
> > or something like that? Most people don't test on bare-metal targets and
> > won't notice if they break, but given an explicit option to turn off link
> > tests, you could make it a requirement to test that configure works with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > link tests disabled before checking in changes to configure.{ac,in}.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That's a reasonable idea, but as Joseph said, for GNU/Linux (and other
> "hosted" platforms, presumably), we've decided we do need to do links,
> so on those platforms, --without-link-tests would probably result in
> broken libraries.
You wouldn't be using those libraries -- I wouldn't even expect people to
actually wait for the libraries to build -- just check that 'configure
--without-link-tests' runs to completion with no errors, then press ^C.
> > I have a feeling it would be more robust to simulate the link tests
> > inside the autoconf/libtool macros themselves as opposed to explicitly
> > avoiding them in each and every configure.{ac,in}. Supply an option
> > --simulate-link-tests=file_with_results with the default being no and be
> > happy.
>
> We would still need to hard-code things.
Yes. The difference being it wouldn't break the first time someone edits
configure.ac. --simulate-link-tests=file would be similar to
--cache-file=file, but anything not specified in 'file' would default to
'no' instead of being probed for. We would ship a file with the hard-coded
answers. It would need no hacks, tricks or work-arounds in configure.ac, and
it would deal with all the libraries, present, past and future, in one fell
swoop.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
next prev parent reply other threads:[~2007-11-30 18:17 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 [this message]
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
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=20071130181424.GO17368@sygehus.dk \
--to=rask@sygehus.dk \
--cc=bernds_cb1@t-online.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=jzhang918@gmail.com \
--cc=mark@codesourcery.com \
--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).