I found this just now. I'm afraid I don't know enough about gcc to deduce whether this is just yet another symptom of problems already reported or something else, that genuinely matters (I think it does) and that can be mended (I hope it can).
I just repeatedly used gcc with hello.c attached to get this: ~/tmp> gcc -o hello hello.c; md5sum hello.exe 15fbfaadc53cede5d797eb544dae032e *hello.exe ~/tmp> gcc -o hello hello.c; md5sum hello.exe 3a7d9a1536e0b3dcb4fa8557a2933ffb *hello.exe ~/tmp> gcc -o hello hello.c; md5sum hello.exe 952a3bee8d35b627a92c679640e1d1df *hello.exe The fact that hello.exe alters seems a bit non-optimal to me, given that md5sums are a pretty standard way for people like you and me to check that we're running the same stuff, intended to do the same thing. Incidentally, it's always the same two bytes that alter: ~/tmp> cmp -l hello.exe hello1.exe 137 74 254 217 33 213 ~/tmp> cmp -l hello.exe hello2.exe 137 74 257 217 33 216 ~/tmp> cmp -l hello.exe hello3.exe 137 74 262 217 33 221 I had an earlier problem with a _long_ myfile.c giving variant myfile.exe. I knew you wouldn't like to be bothered with myfile.c which is why I looked at hello.c. The variations in successive copies of myfile.exe were again in bytes 137 and 217. Fergus
hello.c
Description: Binary data
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
