This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bad bug in ar (or ranlib?)


> Mailing-List: contact binutils-help@sourceware.cygnus.com; run by ezmlm
> List-Unsubscribe: <mailto:binutils-unsubscribe-geoffk=cygnus.com@sources.redhat.com>
> List-Subscribe: <mailto:binutils-subscribe@sources.redhat.com>
> List-Archive: <http://sources.redhat.com/ml/binutils/>
> List-Post: <mailto:binutils@sources.redhat.com>
> List-Help: <mailto:binutils-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
> Date: Wed, 19 Jul 2000 10:34:14 +0200
> From: Cyrille Artho <cartho@mordor.ch>
> X-Accept-Language: en
> 
> Hi all,
> under Linux/i686/g++, I try to compile a large set of C++ files that
> compile under Solaris with Sun's latest compiler (SunWspro version 5).
> The C++ files make no use of exceptions or templates. They do, though,
> include a C API in the C++ files, and C code (.c) and header files,
> which partially contain C++ code in return (no, I did not write that
> myself). This means that the source files have abundant 'extern "C"'
> declarations, and even some 'extern "C++"' parts.
> When I try to compile the entire bunch of files, the output is
> inconsistent! The source files are the same, though, and the time is not
> included as a command line option for the version string (only the date
> is used).

They shouldn't vary much.  Sometimes g++ does need to include a short
random string in an object file, but other than that if you give it
exactly the same input it should produce exactly the same output.
You can usually spot the random strings because the files will only
differ in about 8 consecutive bytes, which will be ASCII characters.

> First, the .o files (from g++ -c) slightly differ, but I guess this is
> because g++ uses some short random strings for the object file. I think
> all .o files I got are always working (I could not test them every
> time). The size of the .o files is always the same, and the first byte
> that differs always has the same offset (but different .o files have
> offsets ranging from ~30 to several 10K bytes).
> 
> However, when I build a static library with ar, the library sometimes
> differs in size, and as a result of that is not working! I get numerous
> errors like
> --
> BFD: ../objlx/UTraceOut.o: invalid string offset 1769472 >= 958 for
> section `.shstrtab'
> ..
> BFD: UTraceOut.o: invalid string offset 1769472 >= 958 for section
> `.shstrtab'
> all the time
> --
> I get about 30 such error messages, once for "ar" (where it says
> ../objlx) and once again for ranlib which encounters a broken archive.
> The error messages do *not* always occur at the same place (not even in
> the same object file).
> When I run 'nm' later to check the .a file, I also get (before the other
> error messages):
> nm: utablecmp.o: File truncated
> nm: UListPool.o: File truncated

Now, that's a more serious problem.  Can you come up with a short testcase?

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]