Re: question about "invalid string offset" & "could not read symbols: Malformed archive" linker errors (fwd)

2008-08-26 Thread Nick Clifton
Hi Roger, In archive outdir/debug/libxvtxmapi.a: objdump: tapp.o: File format not recognized [EMAIL PROTECTED] xvtxmapid.dir]$ objdump -p tapp.o tapp.o: file format elf32-i386 Oh dear. So it would appear that tapp.o is being corrupted when it is added to the libxvtmapi.a archive. I

[Bug ld/6727] Thumb interworking code zero when another section is positioned before positioning .text

2008-08-26 Thread nickc at redhat dot com
--- Additional Comments From nickc at redhat dot com 2008-08-26 11:13 --- Hi Aaron, OK then. I have checked the patch into the sources so it will be in the next official release of the binutils. Cheers Nick PS. For the record this is the ChangeLog entry I included when I checked

[Bug gold/6858] New: Linking with -shared should imply --allow-shlib-undefined

2008-08-26 Thread kris dot van dot hees at oracle dot com
The old linker enabled --allow-shlib-undefined behaviour when the -shared option is passed. Gold doesn't currently do that, causing various projects to not build correctly. The patch to fix this problem is quite trivial: RCS file: /cvs/src/src/gold/options.cc,v retrieving revision 1.75 diff -r1.

[Bug gold/6859] New: Symbols specified as -u may erroneously get added to the dynsym table

2008-08-26 Thread kris dot van dot hees at oracle dot com
Gold handles explicitly undefined symbols (-u ) differently from how the old GNU linker handles then. With gold, if the symbol does not appear defined in any input object, it is added to both the symtab (symbol table) and the dynsym (dynamic symbol table) as an undefined symbol.

Re: question about "invalid string offset" & "could not read symbols: Malformed archive" linker errors (fwd)

2008-08-26 Thread Roger Moore
Hi Nick, On Tue, 26 Aug 2008, Nick Clifton wrote: > >>> In archive outdir/debug/libxvtxmapi.a: > >>> objdump: tapp.o: File format not recognized > > > [EMAIL PROTECTED] xvtxmapid.dir]$ objdump -p tapp.o > > tapp.o: file format elf32-i386 > > > Oh dear. So it would appear that tapp.o is b