linux-mips
[Top] [All Lists]

Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5

To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Subject: Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Tue, 24 May 2005 12:40:28 +0100 (BST)
Cc: Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org
In-reply-to: <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 24 May 2005, Stanislaw Skowronek wrote:

> I tried objcopy (it was my first thought), for one reason or another it
> didn't work (internal BFD error something). Reportedly ECOFF is belly-up
> in current GNU binutils - at least it is what I heard.

 And the bug report is...  Well, where?

> My input is elf32-tradbigmips. So I entirely don't care for binutils'
> ECOFF anymore, and I consider this a good thing. As I said, objcopy didn't
> work at all. Fixing BFD is not my job (it's a monster of Frankensteinian
> proportions), I think that it is actually much easier to write my own
> converter (well, I did it, and it works - except that funny HI/LO mismatch
> I'm going to work around).

 Well, you are not required to fix BFD, but if you don't even report 
problems they are going to be left undiscovered forever...

  Maciej

<Prev in Thread] Current Thread [Next in Thread>