This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problem while configuring target-libiberty while building crosscompiler


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]