gcc binary output differs whether it is built from *.o or *.a

[BEAUGY Alexandre]

Dear Ian and Michael,

Thanks a lot for your answers, which both focuses on ar 
non-deterministic behaviour (in binutils versions prior to 2.20).

And to the solutions you proposed, i.e. use a more recent version of 
binutils (>=2.20) + activate the D modifier to generate a deterministic 
archive.

Nevertheless, I'm currently working on an RHEL4.4 which still uses a 
binutils v2.15.92.0.2-21, and I'm stuck with it. Therefore I will 
continue using my workaround.

Again, thanks a lot to you all.

Regards,

-- 
Alexandre Beaugy

On 08/01/2010 16:46, Ian Lance Taylor wrote:
> Alexandre Beaugy<beaugy.a@free.fr>  writes:
>
>    
>> Then, how does gcc behaves at link time? How did it handles static
>> libraries? Or, how perhaps, the linker behaves? Does gcc pass it a
>> list of object files to link (considering it previously extracted the
>> files from the ar archive)? Why does some binaries, linked with static
>> libs, have a constant checksum, where others cannot consecutively have
>> the same checksum twice, with the same C sources?
>>      
> gcc's behaviour at link time is to pass the arguments to the linker,
> with some prepended files and some appended files and libraries.
>
> When using an archive, the main effect on the linker is the order of
> the symbols in the archive symbol map.  You can see the archive symbol
> map using nm --print-armap on the archive.  The order of the symbols
> in the archive symbol map is determined by the order in which the
> objects are passed to the ar program when creating the archive.
>
> I assume you are using precisely the same ld and ar programs in all
> cases, otherwise all bets are off.
>
> By the way, as of binutils 2.20 GNU ar supports a D modifier to
> generate a deterministic archive, which should always be bitwise
> identical given the same inputs.
>