From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33604 invoked by alias); 10 Aug 2017 20:23:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 33481 invoked by uid 89); 10 Aug 2017 20:23:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=disagreed, our X-HELO: mail.headstrong.de Received: from mail.headstrong.de (HELO mail.headstrong.de) (81.7.4.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 20:23:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.headstrong.de (Postfix) with ESMTP id EC1301C00C68; Thu, 10 Aug 2017 22:23:40 +0200 (CEST) Received: from mail.headstrong.de ([127.0.0.1]) by localhost (mail.headstrong.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SIQCtR-97fgF; Thu, 10 Aug 2017 22:23:39 +0200 (CEST) Subject: Re: [PING^4][PATCH v2] Generate reproducible output independently of the build-path To: Jakub Jelinek , Matthias Klose Cc: Jeff Law , GCC Patches References: <20170721161538.7508-1-infinity0@pwned.gg> <3136125b-bd88-7c0b-504e-a4e4de545bbb@redhat.com> <4b6c844f-9a46-4a4b-48c5-9dfeac54b97f@pwned.gg> <7e11eaf0-99fe-e1b3-3396-df7642a56cdc@debian.org> <20170804130534.GE2123@tucnak> From: Ximin Luo Message-ID: <99557f1d-5552-bfd7-fef5-92a6a92685e4@pwned.gg> Date: Thu, 10 Aug 2017 21:15:00 -0000 MIME-Version: 1.0 In-Reply-To: <20170804130534.GE2123@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg00766.txt.bz2 Jakub Jelinek: > On Fri, Aug 04, 2017 at 08:32:33AM -0400, Matthias Klose wrote: >>>> GCC already supports a similar environment variable SOURCE_DATE_EPOCH, which was accepted about 2 years ago in a patch written by one of our GSoC students. We are not planning any more environment variables like this, and are committed to fixing other sources of non-determinism by patching the relevant build scripts. >>> I would have rejected that as well :-) One of the few times I would >>> have disagreed with Bernd. >> >> You can argue that gcc has command line options to set these, but most build >> systems can be influenced by well documented environment variables like CFLAGS, >> CXXFLAGS, LDFLAGS, so adding one more variable like SOURCE_DATE_EPOCH makes >> sense, considering that many tools dealing with timestamps don't even have >> command line options to do these (and there it's not just about compilers). > > Unlike SOURCE_DATE_EPOCH, the other env vars are autoconf/cmake etc. > related, we really shouldn't be adding more of these. > If some package has messed up build system, you can use > CXX='g++ -fwhatever' > or whatever other way to pass flags you want to the compiler or pick the > compiler you prefer to use. > As I said, this is the only envvar that we're planning to add, we're not planning to add any more. Please also see my point in my other email, about how this is really more of a "cancel-out already-existing environment" piece of data, different from other first-class options to GCC. It would be really nice not to have to patch 1800 packages to make them reproducible. X >> [..] -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git