Windows tools produce differant binary files

[Till Straumann]

Mick Davis wrote:

> Hi
>
> We're using the msys environment on windows to build for our coldfire 
> target.  I'm finalising the upgrade to 4.6.99-3, which has produced a 
> small improvement in our target's idle time.
>
> I've got a problem using the rtems4.7-m68k-20060707-1.exe tools, which 
> I also reproduced using the same tools, but built myself, under msys.
>
> The problem is that the binary I'm producing isn't always the same, 
> depending on the PC I use to build it.  3 older PCs using windows 2000 
> produce one .srec, and 2 newer PCs running windows XP produce another. 
> As well as just being suspicious, this is a problem for our quality 
> system, since we support a number of engineers. I was speculating that 
> the level of optimisation may depend on the capabilities of the build 
> machine?
>
> I use a -DNDEBUG=1 compilation flag to keep build system file names 
> out of the output.  I've checked this by running the output .elf 
> through the 'strings' program, and I don't see any file names. 

Just on a side note: be careful with NDEBUG. If this is defined, then 
all 'assert()' statements go away.
The problem is that some of these might have side effects. Careless 
programmers sometimes
write e.g.,  assert( ptr = malloc(s) )

T.

>
>
> I've been through the gcc manual, and none of the environment 
> variables it mentions exist.  I've been adjusting the variables which 
> are different between PCs, but none have an effect.
>
> Looking at the differences in the binaries themselves, the differences 
> appear to be in the code, but harmless. For example, the register d0 
> is used instead of d1.  Either binary appears to run without a problem.
>
> Can anyone point me to something in the build process which might 
> produce these differences? Do the automake files put build information 
> into the executable somewhere?
>
>