bug-binutils
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]