This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: problem while configuring target-libiberty while building crosscompiler
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Gabor Greif <gabor at mac dot com>
- Cc: gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 22 Oct 2003 17:51:23 -0700
- Subject: Re: problem while configuring target-libiberty while building crosscompiler
- References: <9B73CC36-FA9E-11D7-8B7A-000393A34C6C@mac.com>
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