[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/13730] Trying to link against gt.m object code
From: |
jamesmikedupont at googlemail dot com |
Subject: |
[Bug binutils/13730] Trying to link against gt.m object code |
Date: |
Fri, 24 Feb 2012 11:37:51 +0000 |
http://sourceware.org/bugzilla/show_bug.cgi?id=13730
--- Comment #6 from James Michael DuPont <jamesmikedupont at googlemail dot
com> 2012-02-24 11:37:51 UTC ---
Thanks Nick,
Compiled and tested. I will be looking into gtm more in detail.
here are my test results :
address@hidden:~/experiments/binutils$ ./ld/ld-new
~/test/attachment.cgi\?id\=6238
./ld/ld-new: i386 architecture of input file
`/home/h4ck3rm1k3/test/attachment.cgi?id=6238' is incompatible with
i386:x86-64 output
./ld/ld-new: warning: cannot find entry symbol _start; defaulting to
00000000004000b0
/home/h4ck3rm1k3/test/attachment.cgi?id=6238:/home/h4ck3rm1k3/test/attachment.cgi?id=6238:(.text+0x67):
undefined reference to `_Serenji.SHELL'
/home/h4ck3rm1k3/test/attachment.cgi?id=6238:/home/h4ck3rm1k3/test/attachment.cgi?id=6238:(.text+0x6c):
undefined reference to `_Serenji'
./ld/ld-new: a.out(.data): relocation ".data+0xffffffffffffff50 (type
32)" goes out of range
thanks,
mike
On Fri, Feb 24, 2012 at 11:58 AM, nickc at redhat dot com
<address@hidden> wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13730
>
> Nick Clifton <nickc at redhat dot com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |RESOLVED
> CC| |nickc at redhat dot com
> Resolution| |FIXED
>
> --- Comment #5 from Nick Clifton <nickc at redhat dot com> 2012-02-24
> 10:58:33 UTC ---
> Hi James,
>
> I think that gtm does process the binaries before linking. Certainly the
> serenji.o binary cannot be linked on its own. On the other hand, the linker
> should not be aborting in situations like this. Instead it should return an
> error message and a suitable exit value. So I have checked in a patch that
> does just this. With the patch applied I now get this message:
>
> a.out(.data): relocation ".data+0xffffff50 (type 32)" goes out of range
>
> Still not perfect - it does not say why the reloc is out of range - but that
> is
> about that best that the linker can do in this situation.
>
> Cheers
> Nick
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
- [Bug binutils/13730] New: Trying to link against gt.m object code, jamesmikedupont at googlemail dot com, 2012/02/23
- [Bug binutils/13730] Trying to link against gt.m object code, jamesmikedupont at googlemail dot com, 2012/02/23
- [Bug binutils/13730] Trying to link against gt.m object code, jamesmikedupont at googlemail dot com, 2012/02/23
- [Bug binutils/13730] Trying to link against gt.m object code, nickc at redhat dot com, 2012/02/24
- [Bug binutils/13730] Trying to link against gt.m object code, cvs-commit at gcc dot gnu.org, 2012/02/24
- [Bug binutils/13730] Trying to link against gt.m object code, nickc at redhat dot com, 2012/02/24
- [Bug binutils/13730] Trying to link against gt.m object code,
jamesmikedupont at googlemail dot com <=