Re: why would two copies of gcc-2.95.2 yield different output?

[David T-G <davidtg at justpickone dot org>]

Rupert, et al --

...and then Rupert Wood said...
% 
% Fergus Henderson wrote:
% 
% > > Is there perhaps a way for a mere mortal to reverse-engineer the
% > > binaries and see what the differences are?
% > 
% > Use objdump (from the GNU binutils package).
% 
% It may be easier to use the two compilers to generate assembly output
% for a few simple examples and diff those instead; if the assembly code

That also sounds like a good approach.  Um, can you tell me how to do
that? :-)


% is all the same, then the difference is in the assemble or link steps or
% there's a difference in libraries used. You may also get some clues by
% diffing the specs files (found under
% <prefix>/lib/gcc-lib/<machine>/2.95.2/specs) of the two compilers.

Ah; OK.


% 
% In any case, does it matter that the new compiler generates different
% binaries? It depends how seriously you take your binary validation: even

They take it pretty seriously, in fact; this is a DoD contractor.


% if you rebuild the source to a tested binary with a one-line fix, it
% could be argued you should re-run all your tests on the new binary. In

You're absolutely right, but I think that their software validation
process is robust enough that they take a look at minor changes like that
and carefully analyze how they will affect other parts of the system.
[Note that I don't claim that it *really* is, nor do I claim that such
testing is sufficient; the lack of other process control surrounding this
mess, which has brought me here in the first place, leads me to believe
that maybe those claims would be doomed to failure :-)  My only function
is to enable them to pin down their development environment so that when
they come back five years later to do some maintenance, as has prompted
this whole mess, they know what tools they used.  When they first tried
to dust off the old code it wouldn't even compile!]


% that case, you can just ship the binary you've got, bin the old compiler
% and start using the new compiler for all future releases. (Or even jump

I think we'll have to stick with that, but since the old environment is
here (not destroyed or decommissioned) that's not so bad.  If the best we
can do is improve things for projects starting tomorrow, we've still
taken quite a step.


% to a newer GCC version - if you want to stick with 2.95.x then there's
% always 2.95.3, CVS gcc-2_95-branch or vendor, e.g. Debian, patches of
% the CVS; or prehaps you could try GCC 3.1+.) In the worst case, you just

Agreed.


% have to keep the old build environment until your tested binaries reach
% end-of-supported-life: there's no reason you can't start using a new one
% for new builds.

Also agreed, and probably what we'll do.  Along the way we'll freeze the
entire development environment so that people quite updating the programs
in there and changing things out from under themselves!


% 
% Rup.


Thanks a *bunch* to all for their responses! & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) davidtg@justpickone.org * than to live up to them. -- fortune cookie
(work) davidtgwork@justpickone.org
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

Attachment: msg00864/pgp00000.pgp
Description: PGP signature