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/

- Raw text -