On Tue, Jul 14, 2015 at 8:10 PM, strongq <stro...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
