From: gbcshady AT my-deja DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: objcopy problems.
Date: Mon, 12 Feb 2001 11:30:28 GMT
Organization: Deja.com
Lines: 28
Message-ID: <968hgl$pkp$1@nnrp1.deja.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010212092852 DOT 12969H-100000 AT is>
NNTP-Posting-Host: 24.25.151.140
X-Article-Creation-Date: Mon Feb 12 11:30:28 2001 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
X-Http-Proxy: 1.1 x57.deja.com:80 (Squid/1.1.22) for client 24.25.151.140
X-MyDeja-Info: XMYDJUIDgbcshady
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In article <Pine DOT SUN DOT 3 DOT 91 DOT 1010212092852 DOT 12969H-100000 AT is>,
  djgpp AT delorie DOT com wrote:

> How exactly did you produce the binary file?  With what tool(s) and
> what command line(s)?

It's immaterial -- it's just a raw binary file.  The magic of objcopy
(at least in my past experience) is that it will take a raw binary
file, say 'input.bin', and turn it into a valid object file with
symbols defined:

   extern const char _binary_input_bin_start[];
   extern const char _binary_input_bin_end[];
   extern const char _binary_input_bin_size[];

Something is very broken with the interaction of objcopy/ar/nm.  It
almost looks like they are built with different versions of the bfd
library, or one of them really doesn't support coff-go32 like it says
it does.

The format I should be using is coff-go32, right?

Thanks again,
Matthew Conte.


Sent via Deja.com
http://www.deja.com/