Re: question about "invalid string offset" & "could not read symbols: Malformed archive" linker errors (fwd)
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. If you extract a copy from the archive is this version also unreconizable ? Is it the same size as the original version ? Do they compare the same ? Here is the file xvtdsp55/linux_x86/src/ptk/CMakeFiles/xvtxmapi.dir/link.txt: /usr/bin/ar cr ../../lib/libxvtxmapi.a "CMakeFiles/xvtxmapi.dir/tapp.o" > [...] /usr/bin/ranlib ../../lib/libxvtxmapi.a Quick question - if you intercept the libxvtmapi.a build process after the invocation of "ar" but before the invocation of "ranlib" is the version of tapp.o inside the archive unrecognizable ? Ie is the "ar" process or the "ranlib" process that is corrupting tapp.o ? Which versions of "ar" and "ranlib" are you using ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6727] Thumb interworking code zero when another section is positioned before positioning .text
--- 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 the patch in: ld/ChangeLog PR 6727 * emultempl/armelf.em (arm_elf_set_bfd_for_interworking): Scan all input sections in all input bfds and always select the last suitable one, so that interworking stubs are always processed after all other input sections. (arm_elf_before_allocation): Remove redundant use of output_has_begun flag. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=6727 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/6858] New: Linking with -shared should imply --allow-shlib-undefined
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.75 options.cc 766a767,769 > if (this->shared() && !this->user_set_allow_shlib_undefined()) > this->set_allow_shlib_undefined(true); > I'll post it to the mailing list for approval. -- Summary: Linking with -shared should imply --allow-shlib- undefined Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: kris dot van dot hees at oracle dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6858 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/6859] New: Symbols specified as -u may erroneously get added to the dynsym table
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. The old linker only adds the symbol to the symtab in that case. It works fine if the symbol gets defined in an input object. The reason for this problem turns out to be the fact that during input object processing, "-u" symbols are checked as symbol tables are processed. Then, all "-u" symbols are added as undefined symbols unless they were already seen (i.e. it adds all symbols that didn't appear in input object symbol tables). The fix for this problem turns out to be very easy: mark the "-u" symbols that are added after input object processing as not needing dynsym entries. Index: gold/symtab.cc === RCS file: /cvs/src/src/gold/symtab.cc,v retrieving revision 1.107 diff -r1.107 symtab.cc 176a177 > this->dynsym_index_ = -1; -- Summary: Symbols specified as -u may erroneously get added to the dynsym table Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: kris dot van dot hees at oracle dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6859 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: question about "invalid string offset" & "could not read symbols: Malformed archive" linker errors (fwd)
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 being corrupted when it is
> added to the libxvtmapi.a archive.
>
> If you extract a copy from the archive is this version also
> unreconizable ? Is it the same size as the original version ? Do they
> compare the same ?
When I attempt to extract tapp.o from libxvtxmapi.a, I get the malformed
archive problem again,
[EMAIL PROTECTED] debug]$ ar -x libxvtxmapi.a tapp.o
ar: libxvtxmapi.a: Malformed archive
When I compare tapp.o to libxvtxmapi.a in a hex editor, the only part that
is common between the two files is,
007876745F6170705F6765745F64656661756C745F63746F6F6C73007876745F6170705F6765745F66696C65007876745F6170705F7365745F66696C655F70726F636573736564007876745F6170705F6765745F66696C65735F636F756E74007876745F6170705F657363617065007876745F6170705F
Here is the tapp.o file in ASCII. When I visually compare this to what is
in libxvtxmapi.a, they *look* identical but my hex editor indicates they
are different for some reason except for the part that I indicated above,
.ELF4.(.U..S..$..f..t9...D$.ND$...a..D$..D$...$.[]..[].'U(.].u..u.$...t..4$...]..u...]D$.+D$...!..D$..D$...$.t&.U..].u.$]..u...]..v.U..S..$..[].U(.].}..}..u..u.$...tW..t..t$..<$...]..u..}...]..D$D$...!..D$...$.D$..D$...'U(.]..E.E..u.$..E..D$..E...$]u...].'U..S..[]..v.U(.].u..u..}..}t~$...t...t3.E..t$..|$..D$..E..D$..E...$...]..u..}...]..D$.b..D$...!..D$...$.D$...$f...oD$.\.U..S..$..[].xvt_app_process_pending_events../mnt/hgfs/pclinux/trunk/branches/vistanew-xvt5.8update/xvtdsp55/linux_x86/src/ptk/tapp.c.xvt_app_get_default_ctools.xvt_app_get_file.xvt_app_set_file_processed.xvt_app_get_files_count.xvt_app_escape.xvt_app_create.xvt_app_allow_quit...
GCC: (GNU) 4.1.2 20070626 (Red Hat
4.1.2-14)[EMAIL
PROTECTED](...x..."...'...,...,...G...1..._...6...n...;[EMAIL
PROTECTED]|[EMAIL PROTECTED]
...S...*...:...Q...p...1...dtapp.c.xvt_source_file..LC0..LC1..LC2..LC3..LC4..LC5..LC6..LC7.xvt_app_process_pending_events.__i686.get_pc_thunk.bx._GLOBAL_OFFSET_TABLE_.xvtv_errfrm_mark_API.xvtv_app_proc_update.xvtv_errmsg_dispatch.xvtv_errfrm_unmark_API.xvtk_app_process_pending_events.xvt_app_get_default_ctools.xvtv_app_get_default_ctools.xvt_app_get_file.xvtk_app_get_file.xvt_app_set_file_processed.xvtk_app_set_file_processed.xvt_app_get_files_count.xvtk_app_get_files_count.xvt_app_escape.xvtk_app_escape.xvt_app_destroy.xvtv_app_destroy.xvt_app_create.xvtv_mem_get_functions.xvtk_app_create.xvtv_mem_set_functions.xvt_app_allow_quit.xvtk_app_allow_quit.!...,...T...Y...d...i...!...&
..-...E...K...T...\...a"..f$..-...3...?...G...Y&..`(...*...+..<...A...Q,..u...{...
The part that my hex editor indicates is identical between libxvtxmapi.a
and tapp.o is this part,
.xvt_app_get_default_ctools.xvt_app_get_file.xvt_app_set_file_processed.xvt_app_get_files_count.xvt_app_escape.xvt_app_
Do you have any other ways I could extract tapp.o besides using ar?
> > Here is the file
> > xvtdsp55/linux_x86/src/ptk/CMakeFiles/xvtxmapi.dir/link.txt:
> >
> > /usr/bin/ar cr ../../lib/libxvtxmapi.a "CMakeFiles/xvtxmapi.dir/tapp.o"
> > [...]
> > /usr/bin/ranlib ../../lib/libxvtxmapi.a
>
> Quick question - if you intercept the libxvtmapi.a build process after
> the invocation of "ar" but before the invocation of "ranlib" is the
> version of tapp.o inside t
