abe: cross native toolchain compilation for aarch64-linux-gnu

[strongq]

I'm trying to build the toolchain as win32 executable on Ubuntu with ABE.
I'm pretty new with ABE. I followed the FAQ
https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ and Rob's post. Also
checked the MakeRelease.job and slave.sh. I have all packages listed in the
slave.sh installed. So I assume I have all dependencies ready for the build.
Here is what I have done:
Create _build subfolder beside abe
CD to _build and run: ../abe/configure --with-fileserver=148.251.136.42
--with-remote-snapshots=/snapshots-ref
First build this: ../abe/abe.sh --target aarch64-none-elf -build all
It installed the toolchain to
_build/builds/destdir/x86_64-unknown-gnu-linux. I added the bin under it to
my PATH
Then do 2nd round build: ../abe/abe.sh -host i686-w64-mingw32 --target
aarch64-none-elf -build all
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.
What have I missed?
Any where I can find detail instruction like step by step to build Linaro
toolchain for running on Windows host?

Sincerely,

Qyq

[Jim Wilson]

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.

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

[strongq]

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:***@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

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.

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

[Jim Wilson]

Post by strongq
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.
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
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?

Post by strongq
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

[Rob Savoye]

Post by Jim Wilson
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.

Post by Jim Wilson
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 -

[strongq]

I really want to learn about how to make the cross toolchain. I tried a little with Cygwin and MinGW on Windows but there are more problem there. So I want to stick with this Canadian cross.

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.

Under i686-w64-mingw32/aarch64-none-elf, there are only three sub-dir:
binutils-gdb.git~linaro_binutils-2_24-branch-binutils
dejagnu.git~linaro
infrastructure

Under _build/builds/x86_64-unknown-linux-gnu/aarch64-none-elf there folders (sort with create timestamp):
binutils-gdb.git~linaro_binutils-2_24-branch-binutils
binutils-gdb.git~gdb-7.9-branch-gdb
gcc.git~linaro-gcc-4_9-branch-stage2
newlib.git~linaro_newlib-branch
gcc.git~linaro-gcc-4_9-branch-stage1
infrastructure
dejagnu.git~linaro

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?

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

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?

Thanks,

Qyq

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

Post by strongq
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.
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
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?

Post by strongq
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

[Jim Wilson]

Post by strongq
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.

Post by strongq
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.

Post by strongq
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.

Post by strongq
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

[Rob Savoye]

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

In ABE, there is scripts/MakeRelease.job, which is what I use from
Jenkins to build Canadian cross binary releases.

- rob -

[strongq]

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:***@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

Post by strongq
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.

Post by strongq
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.

Post by strongq
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.

Post by strongq
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

[Rob Savoye]

Post by strongq
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.

Post by strongq
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.

Post by strongq
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.

Post by strongq
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 -

[strongq]

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:***@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

Post by strongq
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.

Post by strongq
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.

Post by strongq
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.

Post by strongq
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 -

[strongq]

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

[Victor Chong]

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.

Post by strongq
Hi Rob, Jim,
I'm frequently getting timeout for wget to fetch snapshot. Shouldn't the
--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
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[strongq]

I’m using the –timeout option. As I mentioned below, inside the abe.sh, it limits the maximum timeout setting to 10 seconds.

I modified abe.sh locally by changing ‘lt 11’ below to ‘gt 10’ and it works fine. That’s why I suggest the abe.sh needs to be updated to give user flexibility to increase the timeout setting bigger than 10 seconds.



Thanks,

Qyq



From: Victor Chong [mailto:***@linaro.org]
Sent: Friday, July 17, 2015 12:20 PM
To: strongq
Cc: Rob Savoye; Jim Wilson; Linaro Toolchain Mailman List
Subject: Re: abe: cross native toolchain compilation for aarch64-linux-gnu



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 <***@codeaurora.org <mailto:***@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

[strongq]

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

[Jim Wilson]

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’.

Ubuntu only provides a basic mingw cross compiler. If you want
python, you would have to build that yourself.

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

It should be possible, but it might be easier if you build it on a win32 system.

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

I don't know. But abe is primarily useful for building linux crosses,
which is a complex process involving multiple glibc and gcc builds to
resolve interdependencies between them. Your target is
aarch64-none-elf, which is much simpler to build cross. It would not
be hard to do this build directly without abe. First you build and
install binutils. Then you drop the newlib sources into gcc, and
build and install gcc with the same --prefix used when configuring
binutils.

Jim

[strongq]

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:***@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:***@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

Post by strongq
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.

Post by strongq
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.

Post by strongq
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.

Post by strongq
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

[Jim Wilson]

Post by strongq
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.

I downloaded from files from release.linaro.org to look at the gdb
binaries. The older gdb binary has no debug info, the newer one does.
That explains the 25MB difference. For linux, the debug info isn't
loaded into memory and doesn't affect the run-time, but I don't know
about windows. You can try stripping the binary to see if that helps.

Jim