This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.3 - Error: Link tests are not allowed after GCC_NO_EXECUTABLES
- From: Brian Dessent <brian at dessent dot net>
- To: Hans Kester <kester dot hans at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 11 Mar 2008 06:22:44 -0700
- Subject: Re: GCC 4.3 - Error: Link tests are not allowed after GCC_NO_EXECUTABLES
- References: <email@example.com>
- Reply-to: gcc at gcc dot gnu dot org
Hans Kester wrote:
> I searched for this error and found:
> Wasn't this patched? How do I fix this?
It wasn't actually fixed. That was a very long thread and it's easy to
get confused, particularly since the mailing list archives don't
crossthread across month boundaries very gracefully. Let me see if I
can summarize the history of the issue for posterity.
Target libraries like libstdc++ need to know a lot of details about the
system they are being configured for -- what C library functions and
capabilities are present, and so on. The library can get this
information either by performing configure tests that link test
programs, or by having the needed answers somehow supplied in another
The problem is that with embedded bare-metal newlib targets (i.e.
*-elf), the amount of functionality that the target has depends
significantly on the board support package (BSP) which typically
consists of things like startup code (crt*.o), linker scripts, and low
level syscall implementations (or stubs thereof.) Since these are
things outside the scope of gcc and newlib, it means without some
external source (be it from the hardware vendor or using generic stubs
from libgloss) that a bare metal gcc target cannot link. And that is
what the GCC_NO_EXECUTABLES error means: some configure script is trying
to do a link test but linking was earlier determined to be impossible
due to no linker script (or crt*.o or whatever) being present.
This presents a dilemma if you want to build a bare metal gcc with
anything but plain C support. The libstdc++ configury in particular
dealt with this by special casing newlib bare metal cross targets, such
that a fixed list of capabilities known to be present in newlib were
coded into crossconfig.m4 such that no link tests were necessary.
At some point last year, this stopped working: bare metal newlib targets
were again failing with GCC_NO_EXECUTABLES when trying to configure
libstdc++. The reason was related to an upgraded libtool and
AC_LIBTOOL_DLOPEN which wanted to check for dlopen() support in the
target, and thus why you see the error about searching for shl_load().
Ideally, since it's common for bare metal targets to not even have
shared libraries it should be possible to avoid the question of dlopen()
support by just specifying --disable-shared, but apparently this doesn't
work because AC_LIBTOOL_DLOPEN has to be called before libtool has been
initialized with AM_PROG_LIBTOOL.
The controversy and bulk of the long thread came about how to rectify
this. The first workaround, which started the whole long thread was a
Blackfin-specific patch that papered over the problem by making -msim
implicit when -mfdpic or
-mid-shared-library was given, which artificially allowed link tests to
succeed. Obviously that doesn't help with other targets but I think it
was enough to get the discussion rolling as to what the real nature of
the problem was.
One proposed remedy was apparently to have the user add libgloss to
their tree, and add code to detect this and pass the appropriate flags
down when configuring target libraries, allowing link tests to work.
But there was objection to this because people were uncomfortable with
letting link tests succeed without the user having specified a BSP,
since that increases the potential for a user to build a toolchain whose
configuration does not match with what the actual hardware supports.
Another idea (the one in the link in your message) was to disable that
particular libtool test when cross compiling. That was not acceptable
because it violates the philosophy that cross compilers should produce
identical code to native compilers for a given target. If simply the
fact that you built gcc as a cross caused a change in behavior, then the
utility of cross compilation would be substantially decreased.
Yet another idea was presented to provide a framework wherein the user
could provide a config.cache-like file that would simulate the results
of all of the configure tests having been performed. It seems that
people generally thought that was a good idea in the abstract but there
was some worry that since it required supplying answers to all configure
tests that it would be hard to come up with a suitable "generic" one to
ship with gcc. There seemed to be agreement that it should remain an
optional feature that the user could use if he had a suitable
config.cache, but not something to make the default building of a
toolchain work again.
There was one additional solution discussed: disable libtool's checking
of dlopen() for newlib targets:
<http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01560.html> I think
everyone agreed that this was a suitable compromise, and that the way
forward was to revert the libgloss hacks, implement the config.cache
idea as an optional alternative, and commit the patch to disable
dlopen() checking on newlib.
However nothing seemed to ever actually get committed: neither that
above patch nor the config.cache one seem to have made it into the
tree. I think the thread had diverged somewhat into people discussing
if and how it would be possible to make other target libraries more like
libstdc++ so that they could more easily build for bare metal newlib
targets too. In all of that noise, nobody seems to have committed
anything, and it looks like 4.3.0 went out the door meanwhile.