possible objcopy misfeature

["Matthew Conte" <matt at vvisions dot com>]

Hello.  I'm not sure whether or not I've found a bug in the GNU binutils, so
I will quickly pose my question here.   Please forgive me if this is
off-topic, but I have yet to find anyone in the newsgroups or other mailing
lists who has been knowledgeable enough to answer this question.

I'm using the latest ports of objcopy (on several platforms) to convert a
raw binary file to an object file that can be linked into a gcc program.
This is an operation that can be easily done from most assemblers (INCBIN or
similar), but is a bit more difficult when using gcc/g++.  "raw binary file"
here refers just to any kind of binary data (graphics, sound data,
compressed data, etc.) that I may want to be able to address from within my
code.

The problem is that currently this technique works only on the arm-elf port
of objcopy/binutils.  It does not work in djgpp, linux, or the sparC port.
An example:

$ objcopy -v -I binary -O elf32-little input.bin output.o
> copy from input.bin(binary) to output.o(elf32-little)
> Warning: Output file cannot represent architecture UNKNOWN!
$ nm output.o
> 00000000 D _binary_input_bin_end
> 00000000 A _binary_input_bin_size
> 00000000 D _binary_input_bin_start

This works as expected.  I am then able to link output.o into my executable
and reference these symbols.  But under djgpp/sparC/linux, I get the
following behaviour:

$ objcopy -v -I binary -O coff-go32 input.bin output.o
> copy from input.bin(binary) to output.o(coff-go32)
> Warning: Output file cannot represent architecture UNKNOWN!
$ nm output.o
> c:/djgpp/bin/nm.exe: output.o: File format not recognized

Trying to list contents with objdump similarly fails.

My question is: Is the arm-elf version of objcopy/binutils broken here, or
are all the others?  If so, what is the nature of the fix?

Thank you in advance for any help/guidance.

Regards,
Matthew Conte.