Hans Kester wrote: > I searched for this error and found: > http://gcc.gnu.org/ml/gcc/2007-09/msg00421.html > 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 form. 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. Brian
