Home Original page

Bad bug in ar (or ranlib?)

Cyrille Artho cartho@mordor.ch
Wed Jul 19 01:33:00 GMT 2000 
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).

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

I suspect this is a nasty bug in ar, and may be because g++ uses
different (rather short) strings for connecting the various parts of C++
templates/objects/operators/methods during each compile time. Possibly
the handling of such symbols in 'ar' is not robust enough, and some
constellations of these short g++ strings cause it to fail.
I sometimes also get a file like stX7GTrk during the build process
(output by 'ar', I guess). I am afraid I cannot provide the files for
inspection, because the program I work with is not Open Source; but I
have made a copy of one faulty run, and can run any sets of commands
that may give more insight into this.
Needless to say, the resulting binary produces segmentation faults in
strange places. Different binaries from different compile runs never
have the same size (if they include a static library), and vary in size
up to 30 KB (about 1%)!
--
Regards,
Cyrille Artho - http://artho.com
Alcohol is the anesthesia by which we endure the operation of life.
                -- George Bernard Shaw
More information about the Binutils mailing list