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