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

Discussion:

Roger Moore

2008-08-18 17:24:30 UTC

Hi,

Presently I am attempting to build an application on Linux with GNU ld
version 2.17.50.0.6-5.el5 20061020. When I execute make, it compiles but
when it reaches the linker I receive the following error messages,

make[1]: Entering directory
`/mnt/hgfs/pclinux/trunk/branches/testapp-xvt5.8update/testappwin'
make[1]: Warning: File `../outdir/debug/libtestappwin.a' has modification
time 1.7e+03 s in the future
g++ -g ../outdir/debug/testappwin/testappwin.o -o
../outdir/debug/testappwin.exe -L../outdir/debug -L../winport
-L../outdir/debug/xvtlib -L/usr/X11R6/lib -L../license/lib/license -lflow
-ltestappwin -lcompress -lgeom3d -ltape -ltiff -lfreetype -lwinport
-lxispread -lpwr -lrw -lxvtxmapi -lxvtxmhb500 -lxvtxmba500 -lxvtxmhi500
-lnxpro -lm -lGL -lGLU -lX11 -lXm -llicense -lpthread -lstdc++
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
369098752 >= 0 for section `'
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
33554432 >= 0 for section `'
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
134217728 >= 0 for section `'
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
352321536 >= 0 for section `'
../outdir/debug/libxvtxmapi.a: could not read symbols: Malformed archive
collect2: ld returned 1 exit status
make[1]: *** [../outdir/debug/testappwin.exe] Error 1
make[1]: Leaving directory
`/mnt/hgfs/pclinux/trunk/branches/testapp-xvt5.8update/testappwin'
make: *** [debug] Error 2
[***@localhost testapp-xvt5.8update]$

Do you have any suggestions as to what may the cause of the problem?
Please let me know if you want to see some of the source from tapp.c.

Any help at all would be greately appreciated. Thank you for your time
and I look forward to hearing from you.

Sincerely,

Roger

Nick Clifton

2008-08-19 15:38:54 UTC

Permalink

Hi Roger,

Post by Roger Moore
Presently I am attempting to build an application on Linux with GNU ld
version 2.17.50.0.6-5.el5 20061020.

Please see if you can reproduce this problem using a linker built from
the head of the binutils CVS sources. (I have a feeling that this is a
problem that has already been fixed). If it is still present please
file a bug report at http://sourceware.org/bugzilla/. Please include a
small test case that can reproduce the problem, and please also tell us
which version of gcc you used to compile the tapp.o file. (This problem
could also theoretically be caused by gcc).

Cheers
Nick

Roger Moore

2008-08-20 16:31:46 UTC

Permalink

Hi,

We built the libxvtmapi.a ourselves. Yes, I've tried deleting it and
rebuilding but I still get the file format not recognized error message.
The following lines show the size of the library file:

[***@randyx64-rh5 testapp]$ ls -l
outdir/debug/libxvtxmapi.a
-rw-rw-r-- 1 roger roger 358363 Aug 20 10:09 outdir/debug/libxvtxmapi.a

The build procedure seems to work fine otherwise, though there are some
warning messages. That said, I haven't seen any warning messages that
seem to be related to this issue.

Here is what I get when I attempt for perform an object dump:

[***@randyx64-rh5 testapp]$ objdump -p
outdir/debug/libxvtxmapi.a
In archive outdir/debug/libxvtxmapi.a:
objdump: tapp.o: File format not recognized
objdump: outdir/debug/libxvtxmapi.a: Malformed archive

Here is the tapp.o file:

[***@randyx64-rh5 testapp]$ find . -name tapp.o
./xvtdsp55/linux_x86/src/ptk/CMakeFiles/xvtxmapid.dir/tapp.o

XVT is a platform-independent API that we use for our
application GUI. We have all the source code for this API. Any
suggestions would be greatly appreciated.

Sincerely,

Roger

---------- Forwarded message ----------
Date: Wed, 20 Aug 2008 08:55:25 +0100
From: Nick Clifton <***@redhat.com>
To: Roger Moore <***@ece.ualberta.ca>
Subject: Re: question about "invalid string offset" & "could not read
symbols: Malformed archive" linker errors

Hi Roger,

Post by Roger Moore
g++ -g ../outdir/debug/testappwin/testappwin.o -o

[...]

Post by Roger Moore
../outdir/debug/libxvtxmapi.a: could not read symbols: File format not
recognized
How do you tell why a file format is not recognized? Do you have any
suggestions?

Did you build the libxvtmapi.a archive yourself or is it one that has
been provided to you ? If you built it yourself, can you try deleting
it and rebuilding it, and were there any problems during the build
procedure ?

How big is it ? (Sometimes a problem in a build process can create a
zero-length file, which the linker cannot then process).

Try running this command to find out more about the object files inside
the archive:

objdump -p ../outdir/debug/libxvtmapi.a

Is the file format of the object files what you would expect it to be ?

Cheers
Nick

---------- Forwarded message ----------
Date: Mon, 18 Aug 2008 11:24:30 -0600 (MDT)
From: Roger Moore <***@ece.ualberta.ca>
To: bug-***@gnu.org
Subject: question about "invalid string offset" & "could not read symbols:
Malformed archive" linker errors

Hi,

Presently I am attempting to build an application on Linux with GNU ld
version 2.17.50.0.6-5.el5 20061020. When I execute make, it compiles but
when it reaches the linker I receive the following error messages,

make[1]: Entering directory
`/mnt/hgfs/pclinux/trunk/branches/testapp-xvt5.8update/testappwin'
make[1]: Warning: File `../outdir/debug/libtestappwin.a' has modification
time 1.7e+03 s in the future
g++ -g ../outdir/debug/testappwin/testappwin.o -o
../outdir/debug/testappwin.exe -L../outdir/debug -L../winport
-L../outdir/debug/xvtlib -L/usr/X11R6/lib -L../license/lib/license -lflow
-ltestappwin -lcompress -lgeom3d -ltape -ltiff -lfreetype -lwinport
-lxispread -lpwr -lrw -lxvtxmapi -lxvtxmhb500 -lxvtxmba500 -lxvtxmhi500
-lnxpro -lm -lGL -lGLU -lX11 -lXm -llicense -lpthread -lstdc++
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
369098752 >= 0 for section `'
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
33554432 >= 0 for section `'
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
134217728 >= 0 for section `'
/usr/bin/ld: ../outdir/debug/libxvtxmapi.a(tapp.o): invalid string offset
352321536 >= 0 for section `'
../outdir/debug/libxvtxmapi.a: could not read symbols: Malformed archive
collect2: ld returned 1 exit status
make[1]: *** [../outdir/debug/testappwin.exe] Error 1
make[1]: Leaving directory
`/mnt/hgfs/pclinux/trunk/branches/testapp-xvt5.8update/testappwin'
make: *** [debug] Error 2
[***@localhost testapp-xvt5.8update]$

Do you have any suggestions as to what may the cause of the problem?
Please let me know if you want to see some of the source from tapp.c.

Any help at all would be greately appreciated. Thank you for your time
and I look forward to hearing from you.

Sincerely,

Roger

Nick Clifton

2008-08-22 16:13:22 UTC

Permalink

Hi Roger,

Post by Roger Moore
We built the libxvtmapi.a ourselves. Yes, I've tried deleting it and
rebuilding but I still get the file format not recognized error message.
The build procedure seems to work fine otherwise, though there are some
warning messages. That said, I haven't seen any warning messages that
seem to be related to this issue.

[If all else fails, try fixing the warnings anyway... :-)]

Post by Roger Moore
outdir/debug/libxvtxmapi.a
objdump: tapp.o: File format not recognized
objdump: outdir/debug/libxvtxmapi.a: Malformed archive

This is the cause of the problem - the tapp.o file is not recognized.
One possible cause for this is that the compiler used to build the
tapp.o file is targeted at one particular processor type and the
binutils (including objdump and the linker) are targeted at a different
system type. To check this have a look at the output of "objdump
--help" and compare the supported targets list with the target
displayed as part of the output of "gcc --verbose".

Post by Roger Moore
./xvtdsp55/linux_x86/src/ptk/CMakeFiles/xvtxmapid.dir/tapp.o

What does "objdump -p tapp.o" report ? Is it still unrecognized ? (If
not then this is very worrying. It would mean that placing the tapp.o
file into the libxvtxmapi.a archive has corrupted it).

How was tapp.o built ? (Ie what was the command line used to compile it
and to assemble it).

Cheers
Nick

Roger Moore

2008-08-22 20:10:44 UTC

Permalink

Hi Nick,

Post by Nick Clifton
Hi Roger,

[If all else fails, try fixing the warnings anyway... :-)]

That is an option I will have to explore at some point, I think. :)

Post by Nick Clifton

Post by Roger Moore
outdir/debug/libxvtxmapi.a
objdump: tapp.o: File format not recognized
objdump: outdir/debug/libxvtxmapi.a: Malformed archive

Both the objdump and gcc commands indicate they support the i386
architecture, which is where I am building the testapp. Here is the
output from uname:

Linux randyx64-rh5 2.6.18-53.el5PAE #1 SMP Wed Oct 10 16:48:18 EDT 2007
i686 i686 i386 GNU/Linux

So it is a 64-bit machine but we are running 32-bit Red Hat Enterprise 5
on it. It get identical build errors when I try to build it on 64-bit
Red Hat Enterprise 5 as well.

Post by Nick Clifton

Post by Roger Moore
./xvtdsp55/linux_x86/src/ptk/CMakeFiles/xvtxmapid.dir/tapp.o

What does "objdump -p tapp.o" report ? Is it still unrecognized ? (If
not then this is very worrying. It would mean that placing the tapp.o
file into the libxvtxmapi.a archive has corrupted it).

The results from objdump are very confusing:

[***@randyx64-rh5 xvtxmapid.dir]$ objdump -p tapp.o

tapp.o: file format elf32-i386

[***@randyx64-rh5 xvtxmapid.dir]$

So it looks like objdump thinks tapp.o is OK!?

Post by Nick Clifton
How was tapp.o built ? (Ie what was the command line used to compile it
and to assemble it).

Here are the commands in the makefile that related to tapp (please note
that it is built using GNU Make 3.81, but the make is configured using
cmake version 2.6-patch 1):

# target to build an object file
tapp.o:
cd
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86 &&
$(MAKE) -f src/ptk/CMakeFiles/xvtxmapid.dir/build.make
src/ptk/CMakeFiles/xvtxmapid.dir/tapp.o
.PHONY : tapp.o

# target to preprocess a source file
tapp.i:
cd
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86 &&
$(MAKE) -f src/ptk/CMakeFiles/xvtxmapid.dir/build.make
src/ptk/CMakeFiles/xvtxmapid.dir/tapp.i
.PHONY : tapp.i

# target to generate assembly for a file
tapp.s:
cd
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86 &&
$(MAKE) -f src/ptk/CMakeFiles/xvtxmapid.dir/build.make
src/ptk/CMakeFiles/xvtxmapid.dir/tapp.s
.PHONY : tapp.s

As well, here is the make command in the makefile:

# The main all target
all: cmake_check_build_system
cd
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86 &&
$(CMAKE_COMMAND) -E cmake_progress_start
/home/roger/workspace/branches/testappw-xvt5.8update/xvtdsp55/linux_x86/CMakeFiles
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86/src/ptk/CMakeFiles/progress.make
cd
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86 &&
$(MAKE) -f CMakeFiles/Makefile2 src/ptk/all
$(CMAKE_COMMAND) -E cmake_progress_start
/home/roger/workspace/branches/testapp-xvt5.8update/xvtdsp55/linux_x86/CMakeFiles
0
.PHONY : all

Post by Nick Clifton
Cheers
Nick

FYI, here is the output from objdump and gcc that you requested earlier:

[***@randyx64-rh5 testapp-xvt5.8update]$ objdump --help
Usage: objdump <option(s)> <file(s)>
Display information from object <file(s)>.
At least one of the following switches must be given:
-a, --archive-headers Display archive header information
-f, --file-headers Display the contents of the overall file header
-p, --private-headers Display object format specific file header
contents
-h, --[section-]headers Display the contents of the section headers
-x, --all-headers Display the contents of all headers
-d, --disassemble Display assembler contents of executable
sections
-D, --disassemble-all Display assembler contents of all sections
-S, --source Intermix source code with disassembly
-s, --full-contents Display the full contents of all sections
requested
-g, --debugging Display debug information in object file
-e, --debugging-tags Display debug information using ctags style
-G, --stabs Display (in raw form) any STABS info in the
file
-W, --dwarf Display DWARF info in the file
-t, --syms Display the contents of the symbol table(s)
-T, --dynamic-syms Display the contents of the dynamic symbol
table
-r, --reloc Display the relocation entries in the file
-R, --dynamic-reloc Display the dynamic relocation entries in the
file
@<file> Read options from <file>
-v, --version Display this program's version number
-i, --info List object formats and architectures supported
-H, --help Display this information

The following switches are optional:
-b, --target=BFDNAME Specify the target object format as
BFDNAME
-m, --architecture=MACHINE Specify the target architecture as
MACHINE
-j, --section=NAME Only display information for section NAME
-M, --disassembler-options=OPT Pass text OPT on to the disassembler
-EB --endian=big Assume big endian format when
disassembling
-EL --endian=little Assume little endian format when
disassembling
--file-start-context Include context from start of file (with
-S)
-I, --include=DIR Add DIR to search list for source files
-l, --line-numbers Include line numbers and filenames in
output
-F, --file-offsets Include file offsets when displaying
information
-C, --demangle[=STYLE] Decode mangled/processed symbol names
The STYLE, if specified, can be `auto',
`gnu',
`lucid', `arm', `hp', `edg', `gnu-v3',
`java'
or `gnat'
-w, --wide Format output for more than 80 columns
-z, --disassemble-zeroes Do not skip blocks of zeroes when
disassembling
--start-address=ADDR Only process data whose address is >=
ADDR
--stop-address=ADDR Only process data whose address is <=
ADDR
--prefix-addresses Print complete address alongside
disassembly
--[no-]show-raw-insn Display hex alongside symbolic
disassembly
--adjust-vma=OFFSET Add OFFSET to all displayed section
addresses
--special-syms Include special symbols in symbol dumps

objdump: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32
efi-bsdrv-ia32 efi-rtdrv-ia32 elf32-little elf32-big srec symbolsrec
tekhex binary ihex trad-core
objdump: supported architectures: i386 i386:x86-64 i8086 i386:intel
i386:x86-64:intel

The following i386/x86-64 specific disassembler options are supported for
use
with the -M switch (multiple options should be separated by commas):
x86-64 Disassemble in 64bit mode
i386 Disassemble in 32bit mode
i8086 Disassemble in 16bit mode
att Display instruction in AT&T syntax
intel Display instruction in Intel syntax
att-mnemonic
Display instruction in AT&T mnemonic
intel-mnemonic
Display instruction in Intel mnemonic
addr64 Assume 64bit address size
addr32 Assume 32bit address size
addr16 Assume 16bit address size
data32 Assume 32bit data size
data16 Assume 16bit data size
suffix Always display instruction suffix in AT&T syntax
Report bugs to <http://www.sourceware.org/bugzilla/>.
[***@randyx64-rh5 testapp-xvt5.8update]$

[***@randyx64-rh5 testapp-xvt5.8update]$ gcc --verbose
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
[***@randyx64-rh5 testapp-xvt5.8update]$

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"
"CMakeFiles/xvtxmapi.dir/tcb.o" "CMakeFiles/xvtxmapi.dir/tctl.o"
"CMakeFiles/xvtxmapi.dir/tcxo.o" "CMakeFiles/xvtxmapi.dir/tdebug.o"
"CMakeFiles/xvtxmapi.dir/tdlg.o" "CMakeFiles/xvtxmapi.dir/tdm.o"
"CMakeFiles/xvtxmapi.dir/tdwin.o" "CMakeFiles/xvtxmapi.dir/terr.o"
"CMakeFiles/xvtxmapi.dir/tevent.o" "CMakeFiles/xvtxmapi.dir/tfont.o"
"CMakeFiles/xvtxmapi.dir/tfsys.o" "CMakeFiles/xvtxmapi.dir/tgmem.o"
"CMakeFiles/xvtxmapi.dir/thtml.o" "CMakeFiles/xvtxmapi.dir/timage.o"
"CMakeFiles/xvtxmapi.dir/tiostr.o" "CMakeFiles/xvtxmapi.dir/tlist.o"
"CMakeFiles/xvtxmapi.dir/tmem.o" "CMakeFiles/xvtxmapi.dir/tmenu.o"
"CMakeFiles/xvtxmapi.dir/tnav.o" "CMakeFiles/xvtxmapi.dir/tnotebk.o"
"CMakeFiles/xvtxmapi.dir/tpalet.o" "CMakeFiles/xvtxmapi.dir/tpat.o"
"CMakeFiles/xvtxmapi.dir/tpict.o" "CMakeFiles/xvtxmapi.dir/tpmap.o"
"CMakeFiles/xvtxmapi.dir/tprint.o" "CMakeFiles/xvtxmapi.dir/trect.o"
"CMakeFiles/xvtxmapi.dir/tres.o" "CMakeFiles/xvtxmapi.dir/tsbar.o"
"CMakeFiles/xvtxmapi.dir/tscr.o" "CMakeFiles/xvtxmapi.dir/tslist.o"
"CMakeFiles/xvtxmapi.dir/tstr.o" "CMakeFiles/xvtxmapi.dir/ttimer.o"
"CMakeFiles/xvtxmapi.dir/ttreev.o" "CMakeFiles/xvtxmapi.dir/ttx.o"
"CMakeFiles/xvtxmapi.dir/tvobj.o" "CMakeFiles/xvtxmapi.dir/twin.o"
"CMakeFiles/xvtxmapi.dir/rotated.o" "CMakeFiles/xvtxmapi.dir/xvtcm.o"
/usr/bin/ranlib ../../lib/libxvtxmapi.a

Here is the file
xvtdsp55/linux_x86/src/ptk/CMakeFiles/xvtxmapid.dir/link.txt:

/usr/bin/ar cr ../../lib/libxvtxmapid.a CMakeFiles/xvtxmapid.dir/tapp.o
CMakeFiles/xvtxmapid.dir/tcb.o CMakeFiles/xvtxmapid.dir/tctl.o
CMakeFiles/xvtxmapid.dir/tcxo.o CMakeFiles/xvtxmapid.dir/tdebug.o
CMakeFiles/xvtxmapid.dir/tdlg.o CMakeFiles/xvtxmapid.dir/tdm.o
CMakeFiles/xvtxmapid.dir/tdwin.o CMakeFiles/xvtxmapid.dir/terr.o
CMakeFiles/xvtxmapid.dir/tevent.o CMakeFiles/xvtxmapid.dir/tfont.o
CMakeFiles/xvtxmapid.dir/tfsys.o CMakeFiles/xvtxmapid.dir/tgmem.o
CMakeFiles/xvtxmapid.dir/thtml.o CMakeFiles/xvtxmapid.dir/timage.o
CMakeFiles/xvtxmapid.dir/tiostr.o CMakeFiles/xvtxmapid.dir/tlist.o
CMakeFiles/xvtxmapid.dir/tmem.o CMakeFiles/xvtxmapid.dir/tmenu.o
CMakeFiles/xvtxmapid.dir/tnav.o CMakeFiles/xvtxmapid.dir/tnotebk.o
CMakeFiles/xvtxmapid.dir/tpalet.o CMakeFiles/xvtxmapid.dir/tpat.o
CMakeFiles/xvtxmapid.dir/tpict.o CMakeFiles/xvtxmapid.dir/tpmap.o
CMakeFiles/xvtxmapid.dir/tprint.o CMakeFiles/xvtxmapid.dir/trect.o
CMakeFiles/xvtxmapid.dir/tres.o CMakeFiles/xvtxmapid.dir/tsbar.o
CMakeFiles/xvtxmapid.dir/tscr.o CMakeFiles/xvtxmapid.dir/tslist.o
CMakeFiles/xvtxmapid.dir/tstr.o CMakeFiles/xvtxmapid.dir/ttimer.o
CMakeFiles/xvtxmapid.dir/ttreev.o CMakeFiles/xvtxmapid.dir/ttx.o
CMakeFiles/xvtxmapid.dir/tvobj.o CMakeFiles/xvtxmapid.dir/twin.o
CMakeFiles/xvtxmapid.dir/rotated.o CMakeFiles/xvtxmapid.dir/xvtcm.o
/usr/bin/ranlib ../../lib/libxvtxmapid.a

The only difference as far as I've been able to tell so far between
xvtmapi and xvtmapid is the former is intended for cmake 2.4 while the
latter is intended for cmake 2.6.

Thanks so much--I really appreciate your help! If you have any more
questions or ideas, please feel free to let me know.

Cheers,

Roger

Nick Clifton

2008-08-26 10:48:04 UTC

Permalink

Hi Roger,

Post by Roger Moore

Post by Roger Moore
objdump: tapp.o: File format not recognized

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 ?

Post by Roger Moore
Here is the file
/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

Roger Moore

2008-08-26 19:17:40 UTC

Permalink

Hi Nick,

Post by Nick Clifton

Post by Roger Moore

Post by Roger Moore
objdump: tapp.o: File format not recognized

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,

[***@localhost 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,

.ELF....................................4.....(.................U..S......................$..........f..t9.......D$.N....D$...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.......o....D$.\.................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)...$...symtab..strtab..shstrtab..rel.text..data..bss..rodata.str1.4..rodata.str1.1..rel.data.rel.ro.local..comment..text.__i686.get_pc_thunk.bx..note.GNU-***@...............................................................%.......................................+.......................................0.......2...........j...................?.......2.......N.......................R.......................................N.......................................e.......................................n.......................................................................................................................................8.......................................(...x..................................................................................................................................................................................................................................."...............'...,...........,...G...........1..._...........6...n...........;...}***@.......s......._...............v.......................................................................................................|.......................9.......=.......J...............\***@...1.......w...................................................
...S.......................................................................................*...............:...............Q...p...1.......d................tapp.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?

Post by Nick Clifton

Post by Roger Moore
Here is the file
/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

If I take ranlib out of the link.txt file, and then try to build, I get
the same malformed archive message on libxvtxmapi.a, so it appears that
the corruption occurs before ranlib is called.

The ar and ranlib commands are from the CVS checkout I performed on GNU
Binutils:

[***@localhost debug]$ ar --version
GNU ar (GNU Binutils) 2.18.50.20080822
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later
version.
This program has absolutely no warranty.
[***@localhost debug]$

[***@localhost debug]$ ranlib --version
GNU ranlib (GNU Binutils) 2.18.50.20080822
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later
version.
This program has absolutely no warranty.
[***@localhost debug]$

Do you have any suggestions in terms of how to intercept the build
process? Should I use something like bashdb to step through the makefile?

Here are the settings in cmake,

BUILD_64BIT OFF
BUILD_ALL OFF
BUILD_ARCHITECT OFF
BUILD_CMDLINE ON
BUILD_COMPAT OFF
BUILD_DESIGN OFF
BUILD_DSC ON
BUILD_DSC_XPO OFF
BUILD_DSP OFF
BUILD_DSP_XPO OFF
BUILD_EASYLM_GUI OFF
BUILD_EVAL OFF
BUILD_GUITOOLS OFF
BUILD_NET OFF
BUILD_NOLM ON
BUILD_PTK ON
BUILD_PWR OFF
BUILD_RETIRED OFF
BUILD_SAMPLES OFF
BUILD_SOURCE ON
BUILD_STATIC OFF
BUILD_TESTS OFF
CMAKE_BACKWARDS_COMPATIBILITY 2.4
CMAKE_BUILD_TYPE Debug
SVNVERSIONCOMMAND /usr/bin/svnversion

SVNVERSIONCOMMAND: Path to a program.
Press [enter] to edit option CMake Version 2.4 -
patch 8
Press [c] to configure
Press [h] for help Press [q] to quit without generating
Press [t] to toggle advanced mode (Currently Off)

Thanks so much for your help!

Cheers,

Roger

Nick Clifton

2008-08-27 15:08:03 UTC

Permalink

Hi Roger,

Post by Roger Moore
Do you have any other ways I could extract tapp.o besides using ar?

Nope, sorry.

Post by Roger Moore
Please find libxvtxmapi.a and tapp.o

Well that libxvtxmapi.a is definitely corrupt, and he tapp.o file is OK.

Post by Roger Moore
If I take ranlib out of the link.txt file, and then try to build, I get
the same malformed archive message on libxvtxmapi.a, so it appears that
the corruption occurs before ranlib is called.

OK, then "ar" is the culprit.

Post by Roger Moore
GNU ar (GNU Binutils) 2.18.50.20080822

Looks good - are you sure that this the version being used by cmake ?
Ie is it possible that you have other versions of the ar program in your
search path ?

Post by Roger Moore
Do you have any suggestions in terms of how to intercept the build
process?

First check to see if the corruption takes place if you run the "ar"
command by hand, ie not inside the cmake process. If the corruption
does happen then it is the ar program that is to blame. If the
corruption does not happen then it is the build process/cmake that is to
blame.

If it is "ar" that is to blame, please could you see if you can reduce
the test to as few input object files as possible (whilst still showing
the corruption of tapp.o) and then put them together into a tarball and
email it to me, along with a copy of the exact command line that you
have been using. Ie I would like to try to reproduce the corruption locally.

Cheers
Nick

Roger Moore

2008-08-28 17:38:18 UTC

Permalink

Hi Nick,

Post by Nick Clifton

Post by Roger Moore
Do you have any other ways I could extract tapp.o besides using ar?

Nope, sorry.

Post by Roger Moore
Please find libxvtxmapi.a and tapp.o

Well that libxvtxmapi.a is definitely corrupt, and he tapp.o file is OK.

OK, then "ar" is the culprit.

Post by Roger Moore
GNU ar (GNU Binutils) 2.18.50.20080822

Looks good - are you sure that this the version being used by cmake ?
Ie is it possible that you have other versions of the ar program in your
search path ?

It turns out there *is* another ar in the path:

[***@localhost pclinux]$ ls /usr/bin/ar
/usr/bin/ar
[***@localhost pclinux]$ /usr/bin/ar --version
GNU ar 2.17.50.0.6-5.el5 20061020
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
[***@localhost pclinux]$

The ar located in /usr/local/bin is the one that is version 2.18.
Interesting!

Post by Nick Clifton

Post by Roger Moore
Do you have any suggestions in terms of how to intercept the build
process?

If I explicitly run the *correct* ar command by hand,

/usr/local/bin/ar cr ../../lib/libxvtxmapi.a
"CMakeFiles/xvtxmapi.dir/tapp.o" "CMakeFiles/xvtxmapi.dir/tcb.o"
"CMakeFiles/xvtxmapi.dir/tctl.o" "CMakeFiles/xvtxmapi.dir/tcxo.o"
"CMakeFiles/xvtxmapi.dir/tdebug.o" "CMakeFiles/xvtxmapi.dir/tdlg.o"
"CMakeFiles/xvtxmapi.dir/tdm.o" "CMakeFiles/xvtxmapi.dir/tdwin.o"
"CMakeFiles/xvtxmapi.dir/terr.o" "CMakeFiles/xvtxmapi.dir/tevent.o"
"CMakeFiles/xvtxmapi.dir/tfont.o" "CMakeFiles/xvtxmapi.dir/tfsys.o"
"CMakeFiles/xvtxmapi.dir/tgmem.o" "CMakeFiles/xvtxmapi.dir/thtml.o"
"CMakeFiles/xvtxmapi.dir/timage.o" "CMakeFiles/xvtxmapi.dir/tiostr.o"
"CMakeFiles/xvtxmapi.dir/tlist.o" "CMakeFiles/xvtxmapi.dir/tmem.o"
"CMakeFiles/xvtxmapi.dir/tmenu.o" "CMakeFiles/xvtxmapi.dir/tnav.o"
"CMakeFiles/xvtxmapi.dir/tnotebk.o" "CMakeFiles/xvtxmapi.dir/tpalet.o"
"CMakeFiles/xvtxmapi.dir/tpat.o" "CMakeFiles/xvtxmapi.dir/tpict.o"
"CMakeFiles/xvtxmapi.dir/tpmap.o" "CMakeFiles/xvtxmapi.dir/tprint.o"
"CMakeFiles/xvtxmapi.dir/trect.o" "CMakeFiles/xvtxmapi.dir/tres.o"
"CMakeFiles/xvtxmapi.dir/tsbar.o" "CMakeFiles/xvtxmapi.dir/tscr.o"
"CMakeFiles/xvtxmapi.dir/tslist.o" "CMakeFiles/xvtxmapi.dir/tstr.o"
"CMakeFiles/xvtxmapi.dir/ttimer.o" "CMakeFiles/xvtxmapi.dir/ttreev.o"
"CMakeFiles/xvtxmapi.dir/ttx.o" "CMakeFiles/xvtxmapi.dir/tvobj.o"
"CMakeFiles/xvtxmapi.dir/twin.o" "CMakeFiles/xvtxmapi.dir/rotated.o"
"CMakeFiles/xvtxmapi.dir/xvtcm.o"

It gives me this ouput:

/usr/local/bin/ar: ../../lib/libxvtxmapi.a: Malformed archive

Post by Nick Clifton
If it is "ar" that is to blame, please could you see if you can reduce
the test to as few input object files as possible (whilst still showing
the corruption of tapp.o) and then put them together into a tarball and
email it to me, along with a copy of the exact command line that you
have been using. Ie I would like to try to reproduce the corruption locally.

Okay, I'll send the files to you shortly. The command I'm using is
simply 'make'.

Thank you,

Roger