From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by sourceware.org (Postfix) with ESMTPS id 4B4193858D3C for ; Sat, 20 Nov 2021 08:42:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B4193858D3C Received: by mail-lf1-x131.google.com with SMTP id k37so54791572lfv.3 for ; Sat, 20 Nov 2021 00:42:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=vr2/NweyWD+Fo29QcipkP3L/0aSYDhUMi3k3zpp6ujk=; b=MenD2ox8j219Fr1QEz6CtBfBRLzpC0/8hfNIuk3X3oZoOXnLob4r5Y+vpQp4zWUEFa X9g82K6bIXk+V+GdGaK3CPUL9Mc3FJoPTWXUSoWcuaXX6cx+Hn44opQAoNLb/bPical3 i+gTbNoLof9tloswojpzcZHvNQWbUC3m9uTIwWUxFk+ByF5LbC8xIidn9sqM1j3fT57X eGrGAgUksHI/IsFLHgULuFZuG9b68lWtD+/USISOxuCGcNt3tOaXEHI17Y5pmihpK6ox ozFPdT6dSPRVsv09rsnSb8WYJwCOXGJDyBT+vnpqFeGwFf/xMfTBBYg7iUDEOkiCd+K5 ff1Q== X-Gm-Message-State: AOAM530cDi5iIlWBZ0gBaRC/IJw48vNpCOo8qD8T9FP6iHblyFHksWFW pM65j7rQc9pRRPobBd6makk= X-Google-Smtp-Source: ABdhPJwyZ5k89+T/CanrT4qFy2bWY5hQbu6F2ATHOLOQzguY7liuoRb/oMXjKh7MD6bXuycbkOtl3w== X-Received: by 2002:ac2:4bc1:: with SMTP id o1mr40401950lfq.183.1637397771771; Sat, 20 Nov 2021 00:42:51 -0800 (PST) Received: from [192.168.10.175] (37-247-29-68.customers.ownit.se. [37.247.29.68]) by smtp.gmail.com with ESMTPSA id a4sm253848lfo.291.2021.11.20.00.42.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Nov 2021 00:42:51 -0800 (PST) Message-ID: <709a5d8c-b239-06cf-0598-2bf059fd8b4f@gmail.com> Date: Sat, 20 Nov 2021 09:42:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [RFC PATCH] gcc: Improve reproducability when building cc1/cc1plus Content-Language: en-US To: Jakub Jelinek , Andrew Pinski Cc: GCC Patches References: <20211120081748.1160013-1-jacob.kroon@gmail.com> <20211120083221.GY2646553@tucnak> From: Jacob Kroon In-Reply-To: <20211120083221.GY2646553@tucnak> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2021 08:42:55 -0000 On 11/20/21 09:32, Jakub Jelinek wrote: > On Sat, Nov 20, 2021 at 12:24:21AM -0800, Andrew Pinski via Gcc-patches wrote: >> On Sat, Nov 20, 2021 at 12:18 AM Jacob Kroon via Gcc-patches >> wrote: >>> >>> cc1/cc1plus both include a checksum of the object files, archives and >>> options used during linking. Unless the host binutils has been built >>> with --enable-deterministic-archives, the archives will have different >>> checksums each build due to changes in timestamps of the containing >>> object files, and thus the checksum that is embedded in cc1/cc1plus will >>> also change. >>> >>> Fix this by passing "D" to ar/ranlib when creating the archives. >> >> How portable is the D option? That does it work with Mac OS X's ar; >> what about AIX's ar; what about Solaris's ar, etc? >> GNU binutils is not the only ar which is supported for the host. > > It isn't portable and even if ar/ranlib do support that option, not all > users will want it, so forcing it upon them unconditionally is IMO not a > good idea. If anything, configure needs to check if those options are > supported and there needs to be preferrably non-default gcc configure > option to request it. > Aha, I see. Then perhaps an easier and more portable solution for improving the reproducibility would be to make it optional whether or not to include the archives when calculating the checksums. Or perhaps by checksumming the containing object files instead of the archives themselves ? Would something like that be acceptable ? Jacob