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 08:15:56AM -0800, Mark Mitchell wrote:
>
> If I'm understanding correctly:
>
> * You, Benjamin, and I think the previous behavior was best.
>
> * Bernd is flexible, as long as it works.
>
> * Rask prefers the new behavior because he thinks it will be more robust.
>
> Rask, we may have to agree to disagree, as it's clear we both understand
> the pros and cons. I agree that making things link is more likely to
> work, in the sense that it puts a lower burden on run-time library
> configure scripts -- but I also think it increases the risk that the
> configure scripts get the wrong answer.
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.
> And, in some cases, there isn't
> any way to get a bare-metal toolchain to link; the necessary bits may be
> outside Newlib itself and provided only by the end user.
That's not in itself a problem; you could supply --with-sysroot assuming
you have all the necessary parts built already. It's only when you need GCC
to build those other parts needed to link that it becomes a mess. At the
moment, --with-newlib is a special case in that it allows you to configure
and build a newlib target from scratch with just "configure ...; make" while
e.g. glibc and uClibc targets need a more elaborate process, including
building GCC twice in many cases, and perhaps installing intermediate
libraries to satisfy link tests. A more general --with-libc=dirname option
would configure and build in "dirname", then configure libstdc++ etc. with a
"-B dirname" option to make link tests work.
> But, for a bare-metal toolchain, I don't think we need that. So, I'm
> guessing that:
>
> if test "x${with_newlib}" != "xyes"; then
> AC_LIBTOOL_DLOPEN
> fi
>
> will fix the problem.
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}.
> (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)
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. A bit like having created config.cache by hand before configuring, I
suppose.
> Bernd, Richard, Rask, would one of you be willing to explore that route?
I see that Richard has already started, so I'll leave it to him.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year