http demo in network-demos

[Ralf Corsepius]

Following up my own posting ...

On Thu, 2003-09-18 at 07:41, Ralf Corsepius wrote:
> On Thu, 2003-09-18 at 07:09, Jay Monkman wrote:
> > On Thu, Sep 18, 2003 at 06:47:23AM +0200, Ralf Corsepius wrote:
> > > All this sounds like code rott.
> > 
> > That's what I'd guess, but I thought the demos were built for each
> > snapshot.
> These are Joel's babes ;)
> 
> > > Which gcc are you using? Vanilla gcc-3.x probably won't work.
> > 
> > I'm using the gcc-3.2.3 RPM from ftp.rtems.com.
> > 
> > > Do the tests/samples compile? If yes, comparing the calls to gcc there
> > > and in your case probably will help.
> > 
> > They work fine. As far as I can tell, nothing else uses objcopy to
> > generate a linkable object (.o).
> I am pretty sure, we've had this issue before :(
> 
> May-be this helps:
> 
> Some experiments with binutils-2.13.2.1 and binutils-2.14:
> 
> # touch test.c
> # arm-rtems4.7-gcc -o test.o -c test.c
> 
> # arm-rtems4.7-objcopy -I binary -O elf32-littlearm test.o test1.o
> 
> No warning (arm-rtems4.7-objcopy = binutils-2.14)
> 
> # arm-rtems4.6-objcopy -I binary -O elf32-littlearm test.o test1.o
> arm-rtems4.6-objcopy: Warning: Output file cannot represent architecture UNKNOWN!
> 
> The same warning as you see it (arm-rtems4.6-objcopy = binutils-2.13.2.1)
> 
> Now explicitly setting the architecture:
> # arm-rtems4.6-objcopy -I binary -B arm -O elf32-littlearm test.o test1.o
> No warning!
> 
> I conclude from this, 
> * you might have touched a bug/deficiency/issue in binutils-2.13.2.1
> that seems to be fixed in binutils-2.14.
> * explicitly setting the -B <arch> argument in calls to objcopy seems to
> be a work-around, however I don't know which <arch> is expected in your
> case :(

I just found this:

binutils-2.14's objcopy has a new option, listing supported archs:

# arm-rtems4.7-objcopy --help
..
--info                        List object formats & architectures
supported
..

# arm-rtems4.7-objcopy --info
BFD header file version 2.14 20030612
elf32-littlearm
...
binary
 (header endianness unknown, data endianness unknown)
  arm
..

=> -B arm probably is correct.

Ralf