Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Date:	Fri, 20 Dec 2002 15:15:36 +0300
From:	egor duda <deo AT logos-m DOT ru>
Reply-To:	egor duda <cygwin AT cygwin DOT com>
Organization:	deo
X-Priority:	3 (Normal)
Message-ID:	<56349465825.20021220151536@logos-m.ru>
To:	fergus AT bonhard DOT uklinux DOT net
CC:	cygwin AT cygwin DOT com
Subject:	Re: Repeated gcc yields differing .exe files
In-Reply-To:	<001201c2a820$26daf9a0$6fc82486@medschool.dundee.ac.uk>
References:	<001201c2a820$26daf9a0$6fc82486 AT medschool DOT dundee DOT ac DOT uk>
MIME-Version:	1.0

Hi!

Friday, 20 December, 2002 fergus AT bonhard DOT uklinux DOT net fergus AT bonhard DOT uklinux DOT net wrote:

fbun> I found this just now. I'm afraid I don't know enough about gcc to deduce
fbun> whether this is just yet another symptom of problems already reported or
fbun> something else, that genuinely matters (I think it does) and that can be
fbun> mended (I hope it can).

fbun> I just repeatedly used gcc with hello.c attached to get this:

~/tmp>> gcc -o hello hello.c; md5sum hello.exe
fbun> 15fbfaadc53cede5d797eb544dae032e *hello.exe
~/tmp>> gcc -o hello hello.c; md5sum hello.exe
fbun> 3a7d9a1536e0b3dcb4fa8557a2933ffb *hello.exe
~/tmp>> gcc -o hello hello.c; md5sum hello.exe
fbun> 952a3bee8d35b627a92c679640e1d1df *hello.exe

fbun> The fact that hello.exe alters seems a bit non-optimal to me, given that
fbun> md5sums are a pretty standard way for people like you and me to check that
fbun> we're running the same stuff, intended to do the same thing. Incidentally,
fbun> it's always the same two bytes that alter:

~/tmp>> cmp -l hello.exe hello1.exe
fbun>   137  74 254
fbun>   217  33 213
~/tmp>> cmp -l hello.exe hello2.exe
fbun>   137  74 257
fbun>   217  33 216
~/tmp>> cmp -l hello.exe hello3.exe
fbun>   137  74 262
fbun>   217  33 221

fbun> I had an earlier problem with a _long_ myfile.c giving variant myfile.exe. I
fbun> knew you wouldn't like to be bothered with myfile.c which is why I looked at
fbun> hello.c. The variations in successive copies of myfile.exe were again in
fbun> bytes 137 and 217.

This is by design. PE specification states that binary files should
have a timestamp field in their header. Obviously, it changes whenever
you rebuild the application. As we generate windows executables we
should comply with standards adopted by microsoft for their platform.
Other option -- i.e. zeroing timestamp in PE header will solve your
problem but may pose problems with compatibility with new versions of
microsoft's OSes and, possibly, other windows software. So i highly
doubt that current situation will change anytime soon.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19


--
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/

- Raw text -