[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: question about "invalid string offset" & "could not read symbols: Ma
Re: question about "invalid string offset" & "could not read symbols: Malformed archive" linker errors (fwd)
Thu, 28 Aug 2008 11:38:18 -0600 (MDT)
On Wed, 27 Aug 2008, Nick Clifton wrote:
> > Do you have any other ways I could extract tapp.o besides using ar?
> Nope, sorry.
> > Please find libxvtxmapi.a and tapp.o
> Well that libxvtxmapi.a is definitely corrupt, and he tapp.o file is OK.
> > 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.
> > address@hidden debug]$ ar --version
> > GNU ar (GNU Binutils) 188.8.131.5280822
> 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:
address@hidden pclinux]$ ls /usr/bin/ar
address@hidden pclinux]$ /usr/bin/ar --version
GNU ar 184.108.40.206.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.
The ar located in /usr/local/bin is the one that is version 2.18.
> > 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
If I explicitly run the *correct* ar command by hand,
/usr/local/bin/ar cr ../../lib/libxvtxmapi.a
It gives me this ouput:
/usr/local/bin/ar: ../../lib/libxvtxmapi.a: Malformed archive
> 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