This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello!
I'm working on making an armv5b-xscale-linux-gnu uClibc-based toolchain with gcc-3.4.3. I based my work on the uClibc patch in contrib. The crtosstool version is something after 0.35, that is named 0.36, but isn't odfficialy released http://sources.redhat.com/ml/crossgcc/2005-05/msg00185.html
Grumble. I'd forgotten about that one. Guess I'm getting soft in my head in my old age. The next version of crosstool better be 0.37, then.
checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make: *** [configure-target-libiberty] Error 1
This looks like http://gcc.gnu.org/PR16838 but no solution is given there.
Jim Wilson explains the general problem a bit here: http://gcc.gnu.org/ml/gcc/2003-10/msg01103.html http://weongyo.org/compiler/jsboard/read.php?table=archive_gcc&no=99718
Basically, it's silly for libiberty to try to link a program at this point, since you don't have a working system library yet.
Whenever you run into a problem with an autoconf test, have a look at the configure script and see if there's an environment variable you can set to give it the answer to the test so it doesn't have to run it.
In this case, I looked a bit, and the magic value might be ac_cv_search_strerror="none required" export ac_cv_search_strerror Good luck. Let us know what happens. - Dan
p.s. FWIW, here's where GCC_NO_EXECUTABLES was introduced: http://sources.redhat.com/ml/binutils/2003-08/msg00419.html It sets gcc_no_link to yes, and refuses to link programs, if it thinks the linker's broken.
Gentoo ran into something similar in libstdc++: http://bugs.gentoo.org/show_bug.cgi?id=55108 http://www.ldsys.net/~cgs/linux-mips/portage-20040916/sys-devel/gcc/files/3.4.1/gcc-3.4.1-glibc-is-native.patch and worked around it by hacking libiberty's configure script to simply not call GCC_NO_EXECUTABLES, since they knew it was wrong.
-- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |