More information about: Bug in ar?

More information about: Bug in ar?

[Cyrille Artho]

A few things I did not mention before: I always built the files from
scratch, because running 'ar ru...' produced too many errors.
The object files from g++ are usually the same, although the *sometimes*
differ. The difference is not, as I previously suspected, in the
mangling strings coming from g++ (these never differ). The outputs of
'nm' are always equal, except for (sometimes) missing symbols and, of
course, offsets.
I finally could reproduce an output where the .o files differed (which
is not often the case) and where 'nm' said "xy.o truncated". Therefore,
the problem may lie in g++.
I will now investigate whether the source code that produces the error
always includes some C code in a C++ file that has not yet been declared
extern "C".
Possibly, the error "file xy truncated" results from g++, while the
error messages 
BFD: UTraceOut.o: invalid string offset 1769472 >= 958 for section
`.shstrtab'
hint at some problem in BFD.
--
Regards,
Cyrille Artho - http://artho.com
Alcohol is the anesthesia by which we endure the operation of life.
                -- George Bernard Shaw

Re: More information about: Bug in ar?

[Alan Modra]

On Wed, 19 Jul 2000, Cyrille Artho wrote:

[snip]
> The object files from g++ are usually the same, although the *sometimes*
> differ.
[snip]
> hint at some problem in BFD.

I'd be more inclined to suspect you have a hardware problem of some
sort.  Compilers are deterministic (barring bugs with uninitialised
variables), so you should always get the same output given the same input.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.