This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GNU Binutils 2.33.1 has been released.


Hi Romain,

What's the easiest way for me to reproduce this?

I've tried

    git clone https://github.com/RomainNaour/buildroot.git buildroot
    cd buildroot
    git checkout binutils-2.33.1

    curl https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/build_fragments/armv7-eabihf--uclibc--bleeding-edge-2018.11-1.defconfig > .config
    make olddefconfig
    make -j

but All I keep hitting are options mismatch in gmp.

Thanks,
Tamar

> -----Original Message-----
> From: Nick Clifton <nickc@redhat.com>
> Sent: Monday, October 14, 2019 6:45 AM
> To: Romain Naour <romain.naour@gmail.com>; Tamar Christina
> <Tamar.Christina@arm.com>
> Cc: binutils@sourceware.org; buildroot <buildroot@buildroot.org>
> Subject: Re: GNU Binutils 2.33.1 has been released.
> 
> Hi Romain,
> 
> > I tested this new version using toolchain-builder project [1] and
> > discovered some regressions on arm cortex-m4 and SH4 architectures.
> 
> > There is a segfault in elf2flt while building busybox:
> > "ld (ld-elf2flt):
> > /builds/kubu93/toolchains-builder/build/opt/armv7m--uclibc--bleeding-e
> > dge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt
> 
> Hmm, that is worrying, but I suppose that it could be a bug in elf2flt rather
> than the binutils.  Maybe...
> 
> Is this problem specific to the ARM architecture ?  (Ie does elf2flt work when
> compiled and run for other architecures ?)  If so, then I would suspect a
> problem with the changes to the ARM specific code in the BFD library, and I
> would probably ask one of the ARM regulars to take a look.  (Hi Tamar...)
> 
> Are you able to find out where the segmentation fault is occurring ?
> Is it inside the BFD library somewhere ?
> 
> 
> > - sh4 [4]: (sh4, binutils 2.33.1, kernel headers 4.19.79, Glibc |
> > uClibc-ng | musl, Qemu 3.1)
> >
> > The system doesn't boot under Qemu.
> 
> *sigh* This one will probably be even harder to investigate.  Not being
> familiar with Qemu, I do not what the best approach would be.  Can we get it
> to tell us why the boot fails ?  Does it think that a binary is invalid somehow ?
> 
> Cheers
>   Nick

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]