As a note, all the builders we use for binary releases run Trusty still. I haven't tried Jessie (should work fine),but I know that newer Mingw releases fail to compile GCC 5.x. - rob -
-------- Original message -------- From: Christophe Lyon christophe.lyon@linaro.org Date: 04/22/2016 14:00 (GMT-07:00) To: Linaro Toolchain Mailman List linaro-toolchain@lists.linaro.org Subject: [ACTIVITY] 18-22 April 2016
* 3 days off
== Progress == * Validation: - fixed ABE master and stable branches to use 'ssh -t' instead of 'ssh -tt' when cross-testing - trying to assert master vs stable before the array branch merge, noticed differences on armv8l - created linaro-local/stable Dejagnu branch (currently a copy of master). Prepared ABE config patches to use it.
* GCC - infrastructure problems (ST compute farm), leading to a lot of noise in the validations (and wrong regression reports upstream) - enabled gcc-6-branch monitoring - added GCC-6 tab to the backports spreadsheet
* Support - Windows-hosted toolchain crashes: it seems the builders we use to make the release run Jessie and not Trusty. Tried to rebuild a toolchain in a Jessie chroot, but the script failed (works under Trusty)
* Misc (conf-calls, meetings, emails, ...)
== Next == * Validation - check that using linaro-local/stable Dejagnu branch works well - create validation reference points before array branch merge - understand/fix armv8l validation differences between master/stable ABE branches
* GCC - trunk monitoring, report regressions if needed - more intrinsics tests
* Support - Windows-hosted toolchain bug
* Snapshots - prepare a few backports for our gcc-5 branch
* Cortex-strings update _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Sat, Apr 23, 2016 at 4:43 PM, Rob Savoye rob.savoye@linaro.org wrote:
As a note, all the builders we use for binary releases run Trusty still. I haven't tried Jessie (should work fine), but I know that newer Mingw releases fail to compile GCC 5.x.
In the weekly status meeting, Maxim and Christophe looked at the Mingw build jobs, and said that they are running on the Hetzners, which are running Jessie.
I can confirm that an abe toolchain build on a Debian 8.4 Jessie machine reproduces the Mingw failures reported in 2073 and 2174. An abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not reproduce the same failures. Jessie has a 4.9.1 mingw cross toolchain. Trusty has a 4.8.2 mingw cross toolchain. This could be a bug in the gcc-4.9.1 release, or it could be a bug with the debian jessie build of the mingw toolchain. I haven't tried debugging the jessie 4.9.1 mingw cross toolchain yet.
I can confirm that an abe toolchain build using -O -g for the gcc build instead of -O2 -g produces a working toolchain that does not fail for the 2073 and 2174 testcases. The patch I used for this is attached. I haven't done any testing other than those testcases, so I don't know if this is really a good toolchain or not.
FYI While looking at this, I ran into two abe build problems. 1) A mingw toolchain build with --disable update fails with a gdb configure error saying that Python.h can't be found. The problem here is that PYTHON_MINGW env var needs to be set in order to find the python header files. This is set in checkout_infrastructure. But checkout_infrastructure is not called when --disable update, so the env var doesn't get set, and the build fails. The env var should be set somewhere else, or maybe set in both the checkout and build functions. 2) A mingw toolchain rebuild after a gcc change fails with a libsanitize error saying the scsi/scsi.h is missing. The problem here is that the the linux kernel headers-install makefile rule is run, which installs header files, and also removes header files that the kernel doesn't think should be there. scsi/scsi.h is one of the files that is removed, which was installed by glibc. The glibc install is not redone, because glibc doesn't need to be rebuilt. Then gcc gets rebuilt, and notices that the scsi/scsi.h file is missing and fails. This problem can presumably be worked around by using "---build gcc" on the abe command line, if you know that only gcc needs to be rebuilt. I didn't reproduce this, or fully investigate it, so it is possible that there is something else going on here.
Jim
On 24 April 2016 at 18:30, Jim Wilson jim.wilson@linaro.org wrote:
On Sat, Apr 23, 2016 at 4:43 PM, Rob Savoye rob.savoye@linaro.org wrote:
As a note, all the builders we use for binary releases run Trusty still. I haven't tried Jessie (should work fine), but I know that newer Mingw releases fail to compile GCC 5.x.
In the weekly status meeting, Maxim and Christophe looked at the Mingw build jobs, and said that they are running on the Hetzners, which are running Jessie.
Strictly speaking, I couldn't confirm the OS version myself, since I cannot connect to the builders :)
I can confirm that an abe toolchain build on a Debian 8.4 Jessie machine reproduces the Mingw failures reported in 2073 and 2174. An
Good to know! On my side, I have so far been unable to build a Mingw toolchain in our Jessie (8.3) build chroot. I'm using ABE's scripts/MakeRelease.job, which succeeds on trusty.
abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not reproduce the same failures. Jessie has a 4.9.1 mingw cross toolchain. Trusty has a 4.8.2 mingw cross toolchain. This could be a bug in the gcc-4.9.1 release, or it could be a bug with the debian jessie build of the mingw toolchain. I haven't tried debugging the jessie 4.9.1 mingw cross toolchain yet.
That's what I feared.
I can confirm that an abe toolchain build using -O -g for the gcc build instead of -O2 -g produces a working toolchain that does not fail for the 2073 and 2174 testcases. The patch I used for this is attached. I haven't done any testing other than those testcases, so I don't know if this is really a good toolchain or not.
Thanks for the investigation, this is quite helpful.
FYI While looking at this, I ran into two abe build problems.
I noticed them, too.
- A mingw toolchain build with --disable update fails with a gdb
configure error saying that Python.h can't be found. The problem here is that PYTHON_MINGW env var needs to be set in order to find the python header files. This is set in checkout_infrastructure. But checkout_infrastructure is not called when --disable update, so the env var doesn't get set, and the build fails. The env var should be set somewhere else, or maybe set in both the checkout and build functions. 2) A mingw toolchain rebuild after a gcc change fails with a libsanitize error saying the scsi/scsi.h is missing. The problem here is that the the linux kernel headers-install makefile rule is run, which installs header files, and also removes header files that the kernel doesn't think should be there. scsi/scsi.h is one of the files that is removed, which was installed by glibc. The glibc install is not redone, because glibc doesn't need to be rebuilt. Then gcc gets rebuilt, and notices that the scsi/scsi.h file is missing and fails. This problem can presumably be worked around by using "---build gcc" on the abe command line, if you know that only gcc needs to be rebuilt. I didn't reproduce this, or fully investigate it, so it is possible that there is something else going on here.
Jim
On 24 April 2016 at 21:05, Christophe Lyon christophe.lyon@linaro.org wrote:
On 24 April 2016 at 18:30, Jim Wilson jim.wilson@linaro.org wrote:
On Sat, Apr 23, 2016 at 4:43 PM, Rob Savoye rob.savoye@linaro.org wrote:
As a note, all the builders we use for binary releases run Trusty still. I haven't tried Jessie (should work fine), but I know that newer Mingw releases fail to compile GCC 5.x.
In the weekly status meeting, Maxim and Christophe looked at the Mingw build jobs, and said that they are running on the Hetzners, which are running Jessie.
Strictly speaking, I couldn't confirm the OS version myself, since I cannot connect to the builders :)
I can confirm that an abe toolchain build on a Debian 8.4 Jessie machine reproduces the Mingw failures reported in 2073 and 2174. An
Good to know! On my side, I have so far been unable to build a Mingw toolchain in our Jessie (8.3) build chroot. I'm using ABE's scripts/MakeRelease.job, which succeeds on trusty.
I forgot to mention that it fails while configuring mpfr for mingw: it complains it cannot find gmp, although it built it just before trying to configure mpfr.
mpfr's config.log contains: configure:15555: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 -ffloat-store -I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include -L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib conftest.c -lgmp >&5 /usr/bin/ld: skipping incompatible /home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a when searching for -lgmp /usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.
abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not reproduce the same failures. Jessie has a 4.9.1 mingw cross toolchain. Trusty has a 4.8.2 mingw cross toolchain. This could be a bug in the gcc-4.9.1 release, or it could be a bug with the debian jessie build of the mingw toolchain. I haven't tried debugging the jessie 4.9.1 mingw cross toolchain yet.
That's what I feared.
I can confirm that an abe toolchain build using -O -g for the gcc build instead of -O2 -g produces a working toolchain that does not fail for the 2073 and 2174 testcases. The patch I used for this is attached. I haven't done any testing other than those testcases, so I don't know if this is really a good toolchain or not.
Thanks for the investigation, this is quite helpful.
FYI While looking at this, I ran into two abe build problems.
I noticed them, too.
- A mingw toolchain build with --disable update fails with a gdb
configure error saying that Python.h can't be found. The problem here is that PYTHON_MINGW env var needs to be set in order to find the python header files. This is set in checkout_infrastructure. But checkout_infrastructure is not called when --disable update, so the env var doesn't get set, and the build fails. The env var should be set somewhere else, or maybe set in both the checkout and build functions. 2) A mingw toolchain rebuild after a gcc change fails with a libsanitize error saying the scsi/scsi.h is missing. The problem here is that the the linux kernel headers-install makefile rule is run, which installs header files, and also removes header files that the kernel doesn't think should be there. scsi/scsi.h is one of the files that is removed, which was installed by glibc. The glibc install is not redone, because glibc doesn't need to be rebuilt. Then gcc gets rebuilt, and notices that the scsi/scsi.h file is missing and fails. This problem can presumably be worked around by using "---build gcc" on the abe command line, if you know that only gcc needs to be rebuilt. I didn't reproduce this, or fully investigate it, so it is possible that there is something else going on here.
Jim
On Sun, Apr 24, 2016 at 12:25 PM, Christophe Lyon christophe.lyon@linaro.org wrote:
mpfr's config.log contains: configure:15555: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 -ffloat-store -I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include -L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib conftest.c -lgmp >&5 /usr/bin/ld: skipping incompatible /home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a when searching for -lgmp /usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.
It did find a libgmp, it just couldn't use it because it was for a different target/ABI.
"gcc" is the wrong compiler for a mingw mpfr build. That should be i686-w64-mingw32-gcc instead. I see that gmp forces use of -m32 for the build. That is harmless for the mingw32 compiler which only emits 32-bit code. But if gmp was also built with "gcc", then you would have a 32-bit x86-linux libgmp and a 64-bit x86_64-linux libmfpr which can't be linked together. So I would suspect that they were both built with the wrong compiler. Not obvious what is wrong, but if you tried a build with CC=gcc in your environment, then it might fail this way.
Jim
On 25 April 2016 at 22:03, Jim Wilson jim.wilson@linaro.org wrote:
On Sun, Apr 24, 2016 at 12:25 PM, Christophe Lyon christophe.lyon@linaro.org wrote:
mpfr's config.log contains: configure:15555: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 -ffloat-store -I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include -L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib conftest.c -lgmp >&5 /usr/bin/ld: skipping incompatible /home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a when searching for -lgmp /usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.
It did find a libgmp, it just couldn't use it because it was for a different target/ABI.
"gcc" is the wrong compiler for a mingw mpfr build. That should be i686-w64-mingw32-gcc instead. I see that gmp forces use of -m32 for the build. That is harmless for the mingw32 compiler which only emits 32-bit code. But if gmp was also built with "gcc", then you would have a 32-bit x86-linux libgmp and a 64-bit x86_64-linux libmfpr which can't be linked together. So I would suspect that they were both built with the wrong compiler. Not obvious what is wrong, but if you tried a build with CC=gcc in your environment, then it might fail this way.
I do not have such a variable in my environment.
Yet, on our Trusty machine we have gcc-mingw-w64 installed (with the i686 and x86_64 variants), but not in the Jessie chroot.
That's probably why the build succeeds on Trusty.
Jim
On 25 April 2016 at 22:12, Christophe Lyon christophe.lyon@linaro.org wrote:
On 25 April 2016 at 22:03, Jim Wilson jim.wilson@linaro.org wrote:
On Sun, Apr 24, 2016 at 12:25 PM, Christophe Lyon christophe.lyon@linaro.org wrote:
mpfr's config.log contains: configure:15555: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 -ffloat-store -I/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/include -L/home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib conftest.c -lgmp >&5 /usr/bin/ld: skipping incompatible /home/christophe.lyon/src/bugs/2073/build/MakeRelease/_build/builds/destdir/i686-w64-mingw32/lib/libgmp.a when searching for -lgmp /usr/bin/ld: cannot find -lgmp
I am in an x86_64 jessie chroot.
It did find a libgmp, it just couldn't use it because it was for a different target/ABI.
"gcc" is the wrong compiler for a mingw mpfr build. That should be i686-w64-mingw32-gcc instead. I see that gmp forces use of -m32 for the build. That is harmless for the mingw32 compiler which only emits 32-bit code. But if gmp was also built with "gcc", then you would have a 32-bit x86-linux libgmp and a 64-bit x86_64-linux libmfpr which can't be linked together. So I would suspect that they were both built with the wrong compiler. Not obvious what is wrong, but if you tried a build with CC=gcc in your environment, then it might fail this way.
I do not have such a variable in my environment.
Yet, on our Trusty machine we have gcc-mingw-w64 installed (with the i686 and x86_64 variants), but not in the Jessie chroot.
That's probably why the build succeeds on Trusty.
Just to confirm: I've updated my chroot image (installed gcc-mingw-w64 & friends). The build succeeded, and I was able to reproduce the compiler crash.
Jim
linaro-toolchain@lists.linaro.org
-
Christophe Lyon -
Jim Wilson -
Rob Savoye