Thanks Wilson for your reply. I was very busy and finally got some time on this. First, I followed your suggestion, built a 'Hello world' program with i686-w64-mingw32-gcc. The generated executable runs well on Windows PC.
So I back to check the config.log file. As I mentioned early, I will build with default host option first. And build with host as i686-w64-mingw32 again.
With the default host option, the config.log shows: configure:5322: result: yes configure:5946: checking for library containing strerror configure:5980: gcc -o conftest -g -O2 -static-libstdc++ -static-libgcc conftest.c >&5
With host option set for mingw32, the config.log shows: configure:5322: result: yes configure:5946: checking for library containing strerror configure:5978: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
Then I checked the 'configure' for libiberty in the snapshot folder. Line 5970~5979 as below: for ac_lib in '' cposix; do if test -z "$ac_lib"; then ac_res="none required" else ac_res=-l$ac_lib LIBS="-l$ac_lib $ac_func_search_save_LIBS" fi if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 fi
And $gcc_no_link is set to 'yes' only happens at line 3164 in configure. Line 3156 ~ 3170 as below: # FIXME: Cleanup? if { { eval echo ""$as_me":${as_lineno-$LINENO}: "$ac_link""; } >&5 (eval $ac_link) 2>&5 ac_status=$? $as_echo "$as_me:${as_lineno-$LINENO}: $? = $ac_status" >&5 test $ac_status = 0; }; then : gcc_no_link=no else gcc_no_link=yes fi if test x$gcc_no_link = xyes; then # Setting cross_compile will disable run tests; it will # also disable AC_CHECK_FILE but that's generally # correct if we can't link. cross_compiling=yes
Based on the last several line, since I'm doing cross compiling, $gcc_no_link should be set to yes. So I'm very confused about this. Frankly, I'm not very familiar with autoconf and those scripts. I just want some simple instruction to do the build for windows. We need the python option for gdb enabled. I also noticed the 4.9.2014.11 Linaro binary, the file size of arm-none-eabi-gdb.exe is about 30M Bytes, and with xml disabled which leads to problem for using it with certain target. The previous 4.8.2014.9 release is less than 5M and it works perfect.
Hopefully you and others can help me understand what I did wrong or missed.
Thank you,
Qyq
-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: Friday, July 10, 2015 6:49 PM To: strongq Cc: Linaro Toolchain Mailman List Subject: Re: abe: cross native toolchain compilation for aarch64-linux-gnu
On Fri, Jul 10, 2015 at 8:49 AM, strongq strongq@codeaurora.org wrote:
First build this: ../abe/abe.sh --target aarch64-none-elf –build all Then do 2nd round build: ../abe/abe.sh –host i686-w64-mingw32 --target aarch64-none-elf –build all
I just tried this on an Ubuntu 14.04 LTS system using the master branch of abe, and the build completed successfully. Not obvious why it didn't work for you.
I did manage to find a minor abe bug, but it didn't stop the build from completing.
However, I’m getting config error while it building libiberty: configure:5946: checking for library containing strerror Configure:5978: error: Link tests are not allowed after GCC_NO_EXECUTABLES. My understanding is that the linker cannot find glibc or eglibc.
Neither mingw32 nor aarch64-elf use glibc/eglibc. They both use newlib. The issue here is that you can't try linking until after you have built gcc and installed its startfiles and libraries. However, gcc needs to do target feature tests as part of its configuration. The solution is that in the gcc configure scripts we try to avoid feature tests that require linking for cross compilers, and if we can't avoid it, then we hard code in the correct answer for known libraries like newlib and glibc.
Anyways, it isn't obvious from the error what is wrong. You need to look at the config.log file in the directory that failed to configure. This will contain info about the configure tests that were run in this dir, and the last one will be the one that failed. You then need to look at this test to see why it failed. In this case, the real error may be earlier, where GCC_NO_EXECUTABLES was set.
If this was the host (i686-w64-mingw32) libiberty that failed, then maybe there is a problem with your i686-w64-mingw32-gcc binary. Can you build a hello world program with it?
Jim