Mail Archives: djgpp-workers/2001/02/15/09:16:50
On Tue, 13 Feb 2001, Matthew Conte wrote:
> Hello, djgpp-workers. I'm having a bit of trouble with objcopy, and I'm not
> quite sure if I should take this to the binutils mailing list, so I thought
> I might present the problem here. I apologize if this is a bit off-topic,
> but I was directed here by someone on comp.os.msdos.djgpp.
This is not off-topic, but perhaps it would indeed be better to post
this to the binutils mailing list, since it looks like a general
question, even if the reason for the problem is DJGPP-specific. I'd
expecte Binutils maintainers to make a sense out of this faster.
> I use the ARM/elf port of the GNU tools for my software development at work,
> and I've been a long-time user of gcc and djgpp at home. As I work in the
> games industry, I routinely need to include large binary files (graphics,
> sound, etc.) into my programs at work. When I used to work in purely ASM,
> this was easy, as most assemblers simply allow you to include binary files.
> Moving to C/C++ made it a tad harder, but I found a way to use objcopy to do
> my dirty work.
First, did you try DJGPP's bin2h utility? It is documented in the
utils.info manual, and might be just what you are looking for.
> Running 'nm' on this file generates:
>
> $ nm output.o
> > c:/djgpp/bin/nm.exe: output.o: File format not recognized
>
> Even though I can clearly see (in a hex editor) the ".data" section tag, and
> the debug symbol names (the aforementioned const char []'s).
The above error message means that the output doesn't look like a COFF
file. The first sign of a non-COFF file is the absence of the COFF
magic signature at the beginning of the file, not of some section. Do
you see the COFF signature in output.o?
- Raw text -