problem while configuring target-libiberty while building cross compiler

[Jim Wilson]

Gabor Greif wrote:
> checking for library containing strerror... configure: error: Link tests 
> are not allowed after GCC_NO_EXECUTABLES.
> make: *** [configure-target-libiberty] Error 1

> Anybody who can explain why this happens, how to fix it and in first 
> place, why target-libiberty is built at all (as opposed to 
> host-libiberty, which is needed by the compiler itself). Is there a 
> configure option to disable it?

Gcc uses libiberty for portability reasons.  We can use functions even 
if the C library doesn't have them.  Some target libraries use libiberty 
for the same reason, libstdc++ in particular, thus we need to build a 
target libiberty.

Since we can't always do link tests for cross targets, the libiberty 
configure has knowledge of a number of targets built into it.  This 
includes targets that are often built as crosses.  This is particularly 
necessary if the C library does not exist yet at the time libiberty is 
configured, which is the case with a unified tree including newlib.  If 
you look for setobjs, you will see special code for newlib based 
targets, vxworks, cygwin, moingw32, uwin, and vms.  If you have usable 
library before building gcc, then it should not be necessary to do 
anything special here.

I think the underlying problem here is the switch from autoconf 2.13 to 
autoconf 2.54.  The older autoconf would just try linking, and only fail 
if it couldn't link anything.  The newer autoconf assumes we can't link 
because of the use of GCC_NO_EXECUTABLES which is not what we want.  I 
know we have ran into the same problem in other places, and have come up 
with workarounds, but offhand I do not know what they are.

You didn't give any details about your source tree or how you are 
configuring, so I can't really answer why the sparc build fails but the 
powerpc one doesn't.  Maybe one is using newlib and the other isn't?  Or 
maybe another library built before libiberty has proper tests (which 
work around the GCC_NO_EXECUTABLES problem), and this library gets built 
for powerpc but not for sparc?  I see one such candidate, libgcj, but 
this theory seems a little far fetched.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com