X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Rebuilding Cygwin From Sources
Date: Mon, 24 Jul 2006 19:06:12 +0100
Message-ID: <01a301c6af4b$d8d4a3a0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <40C729A4D292F64DA98AE016BBA9FFA7DA3D66@HHBRUE005.hq.corp.eurocontrol.int>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On 24 July 2006 18:43, CARTER Alan wrote:

> Hi,
> 
> Perhaps someone who knows can confirm that I've got this right:
> 
> The executables in a Cygwin download can be much older than the download
> date, where "much" > 3 years.

  Yep.  Unless something goes wrong with the efforts to maintain
backward-compatibility (or on the very rare occasions when an ABI-break has to
be deliberately introduced), there should be no problem running an arbitrarily
old cygwin compiled exe against a more up-to-date cygwin dll.

> This suggests that executables are only rebuilt when their own sources
> change. Previously built executables can continue to be bundled into
> downloadable packages, even if the version of gcc in the download is
> much newer.

  Absolutely.  There's no need to rebuild existing executables just because
the compiler changes.

> Therefore, it is not reasonable to attempt to rebuild the executables in
> a download using the sources and gcc in the same download, and expect an
> *exact* reconstruction.

  Yep.  There are other reasons too - things like timestamps and checksums,
embedded strings of filepaths in debug info, and even changes to support
libraries.

> (And that's before thinking about the compilation date strings that end
> up in the executables, or the CFLAGS arguments to the various configure
> scripts which also aren't necessarily obvious.)
> 
> If I know an exact rebuild isn't possible, I won't try to achieve it
> before kludging the source :-)

  You're correct that there are almost certainly many confounding factors that
would make this very different to achieve.  In general, comparing the binary
you've generated on your own local environment to anyone else's is hugely
problematical.

  Note, however, that if you try and build the same sources twice on the
/same/ machine, without having changed or upgraded any part of the system
libs/headers or compiler, you *should* be able to get more-or-less identical
files (although, again, you'd have to make sure all filepaths were the same or
remove the debugging info before comparison.)  Take a look at the gcc
bootstrap build process - it builds the compiler three times, and attempts to
compare the object files from the second and third passes by just stripping
off the file header at the start and comparing the rest of the file, but this
only works because it's using the exact same files and libs and headers and
source dir path and object dir path and everything else because the passes are
all run back-to-back.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/