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.wil...@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 <stro...@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
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
