On Tue, Jul 14, 2015 at 8:10 PM, strongq strongq@codeaurora.org wrote:
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.
Which exact config.log file is this? There are a lot of them. You mentioned libiberty. There should be two libiberty dirs in the gcc build tree for build and host, and one in the binutils tree and one in the gdb tree. I'm guessing this is the host one in the gcc build tree, builds/i686-w64-mingw32/aarch64-none-elf/gcc.git~linaro-gcc-5-branch-stage2/libiberty/config.log.
In my copy of the file, I see configure:6080: checking for library containing strerror configure:6114: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -D__USE_MINGW_ACCES\ S -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c >&5 configure:6114: $? = 0
This compiler is able to link, so we are able to do link tests here. GCC_NO_EXECUTABLES should not be set.
But maybe you are looking at a different config.log file?
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.
abe is not a fool proof tool, and neither are any of the alternatives like crosstool-NG. Learning how to build cross takes a little time. It was fairly simple for me to do the build, using the master branch of abe I just needed to do two abe builds and it worked, but then I have used abe before and already have an environment set up for it to work. It isn't obvious why it didn't work for you. Another alternative is to try doing builds natively on the windows machine. That may or may not be easier.
Offhand I don't know about the gdb issue. I know that we changed from crosstool-ng to abe sometime, late last year I think, so maybe the two gdb's are configured differently.
Jim