This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Link tests after GCC_NO_EXECUTABLES
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