public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dhole <dhole@openmailbox.org>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow embedded timestamps by C/C++ macros to be set externally
Date: Tue, 30 Jun 2015 13:19:00 -0000	[thread overview]
Message-ID: <55929721.4020400@openmailbox.org> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1883 bytes --]

Hi!

We are working in Debian —and I know other free software projects
care— in providing our users with a way to reproduce bit-for-bit
identical binary packages from the source and build environment.
See <https://wiki.debian.org/ReproducibleBuilds/About> for some
rationale and further explanations.

In order to do this, we need to make the build processes deterministic.
As you can imagine, gcc is quite involved in producing Debian packages.
One issue we encounter in many packages that fail to build reproducibly
is the use of the __DATE__, __TIME__ C macros [1], right now we have 456
affected packages that would need patching (either removing the macros,
or passing a known date externally).

A solution for toolchain packages that embed timestamps during the build
process has been proposed for anyone interested and it consists of the
following:
The build environment can export an environment variable called
SOURCE_DATE_EPOCH with a known timestamp in Unix epoch format (In our
case, we use the last date of the package's debian changelog). The
toolchain package running during the build can check if the exported
variable is set and if so, instead of embedding the local date/time,
embed the date/time from SOURCE_DATE_EPOCH.

It would be very beneficial to our project (and other free software
projects working on reproducible builds) if gcc supported this feature.
I'm attaching a patch for gcc-5.1.0 that enables this feature: it
modifies the behavior of the macros __DATE__ and __TIME__ when
SOURCE_DATE_EPOCH is exported.

What do you think? Any suggestions or other ideas that help getting
reproducible builds are welcomed.

I'm willing to extend the documentation if the patch feels appropriate.

Thanks for your attention!

[1] https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros

Best regards,
Dhole

[-- Attachment #1.2: set_DATE_TIME_externally.diff.txt --]
[-- Type: text/plain, Size: 1582 bytes --]

diff --git a/libcpp/macro.c b/libcpp/macro.c
index 1e0a0b5..a52e3cb 100644
--- a/libcpp/macro.c
+++ b/libcpp/macro.c
@@ -349,14 +349,38 @@ _cpp_builtin_macro_text (cpp_reader *pfile, cpp_hashnode *node)
 	     slow on some systems.  */
 	  time_t tt;
 	  struct tm *tb = NULL;
+	  char *source_date_epoch;
 
-	  /* (time_t) -1 is a legitimate value for "number of seconds
-	     since the Epoch", so we have to do a little dance to
-	     distinguish that from a genuine error.  */
-	  errno = 0;
-	  tt = time(NULL);
-	  if (tt != (time_t)-1 || errno == 0)
-	    tb = localtime (&tt);
+	  /* Allow the date and time to be set externally by an exported
+	     environment variable to enable reproducible builds. */
+	  source_date_epoch = getenv ("SOURCE_DATE_EPOCH");
+	  if (source_date_epoch)
+	    {
+	      errno = 0;
+	      tt = (time_t) strtol (source_date_epoch, NULL, 10);
+	      if (errno == 0)
+	        {
+		  tb = gmtime (&tt);
+		  if (tb == NULL)
+		    cpp_error (pfile, CPP_DL_ERROR,
+			       "SOURCE_DATE_EPOCH=\"%s\" is not a valid date",
+			       source_date_epoch);
+	        }
+	      else
+		cpp_error (pfile, CPP_DL_ERROR,
+			   "SOURCE_DATE_EPOCH=\"%s\" is not a valid number",
+			   source_date_epoch);
+	    }
+	  else
+	    {
+	    /* (time_t) -1 is a legitimate value for "number of seconds
+	       since the Epoch", so we have to do a little dance to
+	       distinguish that from a genuine error.  */
+	    errno = 0;
+	    tt = time(NULL);
+	    if (tt != (time_t)-1 || errno == 0)
+	      tb = localtime (&tt);
+	  }
 
 	  if (tb)
 	    {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

             reply	other threads:[~2015-06-30 13:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 13:19 Dhole [this message]
2015-06-30 14:48 ` Manuel López-Ibáñez
2015-06-30 14:49   ` Manuel López-Ibáñez
2015-06-30 15:42     ` Dhole
2015-06-30 16:32       ` Manuel López-Ibáñez
2015-07-03 14:00         ` Dhole
2015-06-30 17:41       ` Martin Sebor
2015-06-30 18:30         ` Mike Stump
2015-06-30 23:21 ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55929721.4020400@openmailbox.org \
    --to=dhole@openmailbox.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).