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

On 07/15/2015 02:13 PM, Jim Wilson wrote:

This compiler is able to link, so we are able to do link tests here. GCC_NO_EXECUTABLES should not be set.

Is the cross compiler built successfully ? I usually only see this error when there isn't a functioning C compiler, or somebody is trying to build C++ in the first stage of the build. The process is Build binutils, then a C compiler, then the sysroot, then GCC again.

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.

We moved away from crosstool-NG in Nov of 2014. Yesterday I was building win32 based cross toolchains for the June snapshot with no problem.

- rob -

On Thu, Jul 16, 2015 at 12:40 PM, strongq strongq@codeaurora.org wrote:

The config.log is under "_build/builds/i686-w64-mingw32/aarch64-none-elf/binutils-gdb.git~linaro_binutils-2_24-branch-binutils/libiberty" My understanding that it is for building the binutils.

Yes. So I was looking at the wrong config.log file. But even in this one, I see that the test for strerror was run. configure:5956: checking for library containing strerror configure:5990: 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:5990: $? = 0

However, I don't have a linaro_binutils-2_24-branch-binutils tree. I have a linaro_binutils-2_25-branch-binutils tree. I mentioned before, I am doing builds on a Ubuntu 14.04LTS (x64_64) system, using the master branch of abe. I don't think that you have mentioned the host OS or the abe branch. You must be using a different abe version. Perhaps there is a bug in the abe version that you have. Or maybe if you are running a different version of linux, maybe there is an interaction problem between abe and that OS that is causing the build failure. Without full info about your setup, I can't reproduce your problems, and hence can't easily help you.

So with default host setting, it will build the binutils last. But why with i686-w64-mingw32 host, it will build this binutils right after building infrastructure? Is it expected or something wrong with my config?

binutils always gets built before gcc. However, it is possible that it was installed last, and that "make install" caused some files to be created inside the binutils dir, such as doc files not created by make all but required by make install. Or maybe binutils was installed first, but was the only dir that created files in the build tree at make install time. Either of these could explain why the binutils dir has the newest timestamp at the end.

I read about Canadian Cross from Wikipedia: https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross

You could also try looking at http://crosstool-ng.org It is another set of scripts like abe to do builds.

But still not fully understand the magic here with ABE. I think the x86_64-unknown-linux-gnu folder is for building the toolchain for ARM target, but runs on Linux PC. But how this could be used for generate toolchain for running on Windows? Seems i686-w64-mingw32-gcc is not involved during the build, isn't it?

The basic process for building a canadian cross requires 3 steps. 1) Build a cross compiler to the host (build=x86_64-linux target=i686-w64-mingw32) 2) Build a cross compiler for the target (build=x86_64-linux target=aarch64-linux) 3) Build a canadian cross compiler (build=x86_64-linux host=i686-w64-mingw32 target=aarch64-linux)

In the third step, we use the compiler from step 1 to create all of the binaries that will run on the host machine. Also, in the third step, we use the compiler from step 2 to create all of the libraries that will run on the target machine.

Abe takes a short cut here, and uses the Ubuntu mingw32 package to supply the compiler for step 1. So we only need to do the last two steps.

Jim

Thanks, Jim. Now I'm clear why it does not need three steps that I originally thought it should be. I'm building on 14.04/x64. lsb_release -r gives me: Release: 14.04 uname -a gives me: Linux ubuntu64 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Also, I did sync to master branch of ABE, because the 'stable' branch does not support " --with-fileserver=148.251.136.42 --with-remote-snapshots=/snapshots-ref " options for configure.

I don't know why I got 2_24 binutils but not 2_25. I will do some check later.

I do have tried on a different Ubuntu PC which has 12.04. And I'm running into problem when do the second around build with host set to i686-w64-mingw32: ld cannot find libmpfr when building mpc. I also noticed on the 12.04 system, it is running gcc (Ubuntu/Linaro 4.4.7-1ubuntu2) but on my 14.04 Ubuntu it is using gcc (Ubuntu 4.8.4-2ubuntu1~14.04). So the first step of the three steps you mentioned make sense here: it needs a right GCC at the start point.

Anyway, I will focus on the 14.04 Ubuntu station and take a look why I'm not getting the right binutils source.

BTW, in another thread Rob mentioned "MakeRelease.job", thank you. I did have a look of this file, also the 'slave.sh' under the same folder. I tried a little by using the -workspace option but got no luck either.

Thanks,

Qyq

-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: Thursday, July 16, 2015 4:32 PM To: strongq Cc: Linaro Toolchain Mailman List Subject: Re: abe: cross native toolchain compilation for aarch64-linux-gnu

On Thu, Jul 16, 2015 at 12:40 PM, strongq strongq@codeaurora.org wrote:

The config.log is under "_build/builds/i686-w64-mingw32/aarch64-none-elf/binutils-gdb.git~linaro_binutils-2_24-branch-binutils/libiberty" My understanding that it is for building the binutils.

Yes. So I was looking at the wrong config.log file. But even in this one, I see that the test for strerror was run. configure:5956: checking for library containing strerror configure:5990: 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:5990: $? = 0

However, I don't have a linaro_binutils-2_24-branch-binutils tree. I have a linaro_binutils-2_25-branch-binutils tree. I mentioned before, I am doing builds on a Ubuntu 14.04LTS (x64_64) system, using the master branch of abe. I don't think that you have mentioned the host OS or the abe branch. You must be using a different abe version. Perhaps there is a bug in the abe version that you have. Or maybe if you are running a different version of linux, maybe there is an interaction problem between abe and that OS that is causing the build failure. Without full info about your setup, I can't reproduce your problems, and hence can't easily help you.

So with default host setting, it will build the binutils last. But why with i686-w64-mingw32 host, it will build this binutils right after building infrastructure? Is it expected or something wrong with my config?

binutils always gets built before gcc. However, it is possible that it was installed last, and that "make install" caused some files to be created inside the binutils dir, such as doc files not created by make all but required by make install. Or maybe binutils was installed first, but was the only dir that created files in the build tree at make install time. Either of these could explain why the binutils dir has the newest timestamp at the end.

I read about Canadian Cross from Wikipedia: https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross

You could also try looking at http://crosstool-ng.org It is another set of scripts like abe to do builds.

But still not fully understand the magic here with ABE. I think the x86_64-unknown-linux-gnu folder is for building the toolchain for ARM target, but runs on Linux PC. But how this could be used for generate toolchain for running on Windows? Seems i686-w64-mingw32-gcc is not involved during the build, isn't it?

The basic process for building a canadian cross requires 3 steps. 1) Build a cross compiler to the host (build=x86_64-linux target=i686-w64-mingw32) 2) Build a cross compiler for the target (build=x86_64-linux target=aarch64-linux) 3) Build a canadian cross compiler (build=x86_64-linux host=i686-w64-mingw32 target=aarch64-linux)

In the third step, we use the compiler from step 1 to create all of the binaries that will run on the host machine. Also, in the third step, we use the compiler from step 2 to create all of the libraries that will run on the target machine.

Abe takes a short cut here, and uses the Ubuntu mingw32 package to supply the compiler for step 1. So we only need to do the last two steps.

Jim

Thank you Rob and Jim. Yesterday I did a git pull. After that, I don't see the problem with configuring libiberty. The build is still running. It finished building newlib and binutil and is building GCC 5 stage2. So I think it should be able to complete the build successfully. You are very kind and helped me to understand better of ABE and cross compiling. Really appreciated.

Thanks a lot and best regards,

Qyq

-----Original Message----- From: Rob Savoye [mailto:rob.savoye@linaro.org] Sent: Thursday, July 16, 2015 10:10 PM To: strongq; 'Jim Wilson' Cc: 'Linaro Toolchain Mailman List' Subject: Re: abe: cross native toolchain compilation for aarch64-linux-gnu

On 07/16/2015 04:30 PM, strongq wrote:

Also, I did sync to master branch of ABE, because the 'stable' branch does not support " --with-fileserver=148.251.136.42 --with-remote-snapshots=/snapshots-ref " options for configure.

'stable' is used more for validation, so doesn't change as often as master. Note that sometime in the next few weeks I hope to move a new fileserver, and then these options won't be needed.

I don't know why I got 2_24 binutils but not 2_25. I will do some check later.

The binutils version shouldn't matter.

I do have tried on a different Ubuntu PC which has 12.04. And I'm running into problem when do the second around build with host set to i686-w64-mingw32: ld cannot find libmpfr when building mpc. I also noticed on the 12.04 system, it is running gcc (Ubuntu/Linaro 4.4.7-1ubuntu2) but on my 14.04 Ubuntu it is using gcc (Ubuntu 4.8.4-2ubuntu1~14.04).

I have a machine still running 12.04, using ABE I do see a problem building a Canadian cross. On 12.04, mingw is using gcc 4.6. On my 14.04 machine, I also have no problems building a Canadian cross with mingw gcc 4.8.

BTW, in another thread Rob mentioned "MakeRelease.job", thank you. I did have a look of this file, also the 'slave.sh' under the same folder. I tried a little by using the -workspace option but got no luck either.

MakeRelease.job is run via Jenkins. Jenkins sets various environment variables before running the script. It's not really designed to be run manually except when I'm debugging it. It's a very simple script, all it really does is build the cross compiler, then the win32 hosted one. You can also run ABE with the --dryrun option, then all it does is print out all the steps without doing anything.

- rob -

You can try the --timeout option to abe.sh to increase the timeout value for wget. Or add "wget_timeout=<value>" to ~/.aberc if you don't want to type it every time.

On Sat, Jul 18, 2015 at 1:04 AM, strongq strongq@codeaurora.org wrote:

Hi Rob, Jim,

I'm frequently getting timeout for wget to fetch snapshot. Shouldn't the timeout setting in abe.sh use gt but not lt as below: --time*|-time*) check_directive $1 timeout "time" $2 if test $2 -lt 11; then wget_timeout=$2 else # FIXME: Range check for non-numerical values. wget_timeout=10 fi

The script limits the timeout setting to be 10 seconds or less. But for slow network connection (I'm from Canada but our http request might be routed to US first), 10 seconds is not enough.

Thanks,

Qyq

---

linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Now I’m running into new problem. I’m trying to enable “--with-python option” for building gdb.

For the native Linux version, I just need to install Python-dev package. But for cross compiling the windows version, I don’t know which Linux package is for mingw. It cannot find the ‘Python.h’.

So I’m just wondering is it possible to build the win32 gdb executable, with the python option enabled?

Another big question, is that possible to use ABE under Cygwin and has anybody tried?

Thanks,

Qyq

Just give a quick update here. I did a git pull and am doing clean build right now. And this time it did pick up 2_25 of binutils. Will give more update tomorrow.

Thanks Jim and Rob for helping on this.

Qyq

-----Original Message----- From: strongq [mailto:strongq@codeaurora.org] Sent: Thursday, July 16, 2015 6:30 PM To: 'Jim Wilson' Cc: 'Linaro Toolchain Mailman List' Subject: RE: abe: cross native toolchain compilation for aarch64-linux-gnu

Thanks, Jim. Now I'm clear why it does not need three steps that I originally thought it should be. I'm building on 14.04/x64. lsb_release -r gives me: Release: 14.04 uname -a gives me: Linux ubuntu64 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Also, I did sync to master branch of ABE, because the 'stable' branch does not support " --with-fileserver=148.251.136.42 --with-remote-snapshots=/snapshots-ref " options for configure.

I don't know why I got 2_24 binutils but not 2_25. I will do some check later.

I do have tried on a different Ubuntu PC which has 12.04. And I'm running into problem when do the second around build with host set to i686-w64-mingw32: ld cannot find libmpfr when building mpc. I also noticed on the 12.04 system, it is running gcc (Ubuntu/Linaro 4.4.7-1ubuntu2) but on my 14.04 Ubuntu it is using gcc (Ubuntu 4.8.4-2ubuntu1~14.04). So the first step of the three steps you mentioned make sense here: it needs a right GCC at the start point.

Anyway, I will focus on the 14.04 Ubuntu station and take a look why I'm not getting the right binutils source.

BTW, in another thread Rob mentioned "MakeRelease.job", thank you. I did have a look of this file, also the 'slave.sh' under the same folder. I tried a little by using the -workspace option but got no luck either.

Thanks,

Qyq

-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: Thursday, July 16, 2015 4:32 PM To: strongq Cc: Linaro Toolchain Mailman List Subject: Re: abe: cross native toolchain compilation for aarch64-linux-gnu

On Thu, Jul 16, 2015 at 12:40 PM, strongq strongq@codeaurora.org wrote:

The config.log is under "_build/builds/i686-w64-mingw32/aarch64-none-elf/binutils-gdb.git~linaro_binutils-2_24-branch-binutils/libiberty" My understanding that it is for building the binutils.

Yes. So I was looking at the wrong config.log file. But even in this one, I see that the test for strerror was run. configure:5956: checking for library containing strerror configure:5990: 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:5990: $? = 0

However, I don't have a linaro_binutils-2_24-branch-binutils tree. I have a linaro_binutils-2_25-branch-binutils tree. I mentioned before, I am doing builds on a Ubuntu 14.04LTS (x64_64) system, using the master branch of abe. I don't think that you have mentioned the host OS or the abe branch. You must be using a different abe version. Perhaps there is a bug in the abe version that you have. Or maybe if you are running a different version of linux, maybe there is an interaction problem between abe and that OS that is causing the build failure. Without full info about your setup, I can't reproduce your problems, and hence can't easily help you.

So with default host setting, it will build the binutils last. But why with i686-w64-mingw32 host, it will build this binutils right after building infrastructure? Is it expected or something wrong with my config?

binutils always gets built before gcc. However, it is possible that it was installed last, and that "make install" caused some files to be created inside the binutils dir, such as doc files not created by make all but required by make install. Or maybe binutils was installed first, but was the only dir that created files in the build tree at make install time. Either of these could explain why the binutils dir has the newest timestamp at the end.

I read about Canadian Cross from Wikipedia: https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross

You could also try looking at http://crosstool-ng.org It is another set of scripts like abe to do builds.

But still not fully understand the magic here with ABE. I think the x86_64-unknown-linux-gnu folder is for building the toolchain for ARM target, but runs on Linux PC. But how this could be used for generate toolchain for running on Windows? Seems i686-w64-mingw32-gcc is not involved during the build, isn't it?

The basic process for building a canadian cross requires 3 steps. 1) Build a cross compiler to the host (build=x86_64-linux target=i686-w64-mingw32) 2) Build a cross compiler for the target (build=x86_64-linux target=aarch64-linux) 3) Build a canadian cross compiler (build=x86_64-linux host=i686-w64-mingw32 target=aarch64-linux)

In the third step, we use the compiler from step 1 to create all of the binaries that will run on the host machine. Also, in the third step, we use the compiler from step 2 to create all of the libraries that will run on the target machine.

Abe takes a short cut here, and uses the Ubuntu mingw32 package to supply the compiler for step 1. So we only need to do the last two steps.

Jim