Re: Binutils build failure on MIPS

2016-09-28 Thread Ludovic Courtès
Hello! Vincent Legoll skribis: > On Tue, Sep 13, 2016 at 10:26 AM, Ludovic Courtès wrote: >> l...@gnu.org (Ludovic Courtès) skribis: [...] >> And now for MIPS! I was so joyful that I almost forgot that >> binutils-cross-boot0-2.27 fails to build on MIPS: >> >> https://hydra.gnu.org/build/1

Re: Binutils build failure on MIPS

2016-09-21 Thread Ludovic Courtès
Hi! Andreas Enge skribis: > On Tue, Sep 13, 2016 at 02:45:40PM +0200, Ludovic Courtès wrote: >> You need a mips64el machine to run: >> ./pre-inst-env guix build -e '(@@ (gnu packages commencement) >> binutils-boot0)' > > I just did this (together with the paramater "-K"!), but the problem is

Re: Binutils build failure on MIPS

2016-09-18 Thread Andreas Enge
Hello, Hello, On Tue, Sep 13, 2016 at 02:45:40PM +0200, Ludovic Courtès wrote: > You need a mips64el machine to run: > ./pre-inst-env guix build -e '(@@ (gnu packages commencement) > binutils-boot0)' I just did this (together with the paramater "-K"!), but the problem is that I have no idea wh

Re: Binutils build failure on MIPS

2016-09-13 Thread Ludovic Courtès
Vincent Legoll skribis: > Hello, > > On Tue, Sep 13, 2016 at 4:05 PM, David Craven wrote: >>> Could that explain the failure ? >> >> It's matched here: >>> mips64*el-*-linux-*)targ_emul=elf32ltsmipn32 > > I'm not sure I understand what your saying: > > $ python import fnmatch fnmat

Re: Binutils build failure on MIPS

2016-09-13 Thread Vincent Legoll
On Tue, Sep 13, 2016 at 4:27 PM, David Craven wrote: > I highly doubt that binutils uses python, and I'm not sure why you > think that this is a filename - so why would unix filename matching > apply in this instance? I know it's not exactly the same, but python fnmatch is probably doing (almost)

Re: Binutils build failure on MIPS

2016-09-13 Thread David Craven
I highly doubt that binutils uses python, and I'm not sure why you think that this is a filename - so why would unix filename matching apply in this instance? There must be a match somewhere... Either mips64*el-*-linux means any cpu model or you've missed a part of the matching code. I remember GC

Re: Binutils build failure on MIPS

2016-09-13 Thread Vincent Legoll
Hello, On Tue, Sep 13, 2016 at 4:05 PM, David Craven wrote: >> Could that explain the failure ? > > It's matched here: >> mips64*el-*-linux-*)targ_emul=elf32ltsmipn32 I'm not sure I understand what your saying: $ python >>> import fnmatch >>> fnmatch.fnmatch('mips64el-linux', 'mips64*el-*-l

Re: Binutils build failure on MIPS

2016-09-13 Thread David Craven
> Could that explain the failure ? It's matched here: > mips64*el-*-linux-*)targ_emul=elf32ltsmipn32 I believe that the -*- part means any cpu model. Since it's a build failure you might get away with cross-compiling. Try passing --target mips64el-linux-gnu (or whatever the mipsel-gcc-toolch

Re: Binutils build failure on MIPS

2016-09-13 Thread Vincent Legoll
> The fix at is > definitely in binutils-2.27.tar.bz2, yet we get an error that suggests > $EMULATION_NAME is empty. Dunno what’s going on. > >> How does one reproduce the failure ? > > You need a mips64el machine to run: I don't have tha

Re: Binutils build failure on MIPS

2016-09-13 Thread Ludovic Courtès
Vincent Legoll skribis: >> Trying to find more infos... > > Thread from April 2015: > > https://sourceware.org/ml/binutils/2015-04/msg00118.html > > But as 2.27 is recent this should already be checked-in... The fix at is definitely in b

Re: Binutils build failure on MIPS

2016-09-13 Thread Vincent Legoll
> Trying to find more infos... Thread from April 2015: https://sourceware.org/ml/binutils/2015-04/msg00118.html But as 2.27 is recent this should already be checked-in... How does one reproduce the failure ? -- Vincent Legoll

Re: Binutils build failure on MIPS

2016-09-13 Thread Vincent Legoll
On Tue, Sep 13, 2016 at 10:26 AM, Ludovic Courtès wrote: > l...@gnu.org (Ludovic Courtès) skribis: > >> ‘core-updates’ is now building with a tiny patch on gcc-4.9 (in fact >> it’s enough to apply it to gcc-cross-boot0, which is interesting): >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71