On 24 April 2016 at 21:05, Christophe Lyon <[email protected]> wrote:
> On 24 April 2016 at 18:30, Jim Wilson <[email protected]> wrote:
>> On Sat, Apr 23, 2016 at 4:43 PM, Rob Savoye <[email protected]> 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.
>
>> 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
_______________________________________________
linaro-toolchain mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Reply via email to