From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AE3953858C01 for ; Thu, 28 Sep 2023 19:27:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE3953858C01 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695929221; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6CCANeY6SeQKs8OcT0q2z1Rj+s760JS5LnliL3zimUI=; b=PIgpOlwLE9Wgwc5nJADZB4an4O6h5LlyTYdL1pNgXfl3JMCT+JDkZwe05aIOJTs4DUEcZ1 xX5W4/umYUiJtnEhhczEuTwvhCb8iLd+th9SRHKvDPKeqsU2R63LukZpCm50m+sFOL+gem NnhTCPZA3yM+lKJ14GuXfCMYRDqnOfU= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-58-XFUC021mO9OIDLVuXr_dTA-1; Thu, 28 Sep 2023 15:26:57 -0400 X-MC-Unique: XFUC021mO9OIDLVuXr_dTA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 40B1538149A1; Thu, 28 Sep 2023 19:26:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9F7BFC15BB8; Thu, 28 Sep 2023 19:26:56 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 38SJQr122686048 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 21:26:54 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 38SJQqO42686046; Thu, 28 Sep 2023 21:26:52 +0200 Date: Thu, 28 Sep 2023 21:26:52 +0200 From: Jakub Jelinek To: Toon Moene Cc: Thomas Koenig , gcc mailing list , gfortran Subject: Re: Test with an lto-build of libgfortran. Message-ID: Reply-To: Jakub Jelinek References: <9e347fa4-1940-46c6-a5c9-899cf5a7ae85@moene.org> <672da73c-e5d2-4512-8ae9-1c36f14f2b97@moene.org> MIME-Version: 1.0 In-Reply-To: <672da73c-e5d2-4512-8ae9-1c36f14f2b97@moene.org> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Sep 28, 2023 at 09:03:39PM +0200, Toon Moene wrote: > > > The full question of "lto-ing" run time libraries is more > > > complicated than just "whether it works" as those who attended the > > > BoF will recall. > > > > I didn't attend the Cauldron (but that discussion would have been > > very interesting).  I think for libgfortran, a first step would be > > additional work to get declarations on both sides to agree (which is > > worth doing anyway). > > > > Best regards > > > >     Thomas > > The big problem in *distributing* GCC (i.e., the collection) with lto'd > run-time libraries is that the format of the lto structure changes with > releases. If a compiler (by accident) picks up a run time library with > non-matching lto objects, it might crash (or "introduce subtle errors in a > once working program"). It is worse than that, usually the LTO format changes e.g. any time any option or parameter is added on a release branch (several times a year) and at other times as well. Though, admittedly GCC is the single package that actually could get away with LTO in lib*.a libraries, at least in some packagings (if the static libraries are in gcc specific subdirectories rather than say /usr/lib{,64} or similar and if the packaging of gcc updates both the compiler and corresponding static libraries in a lock-step. Because in that case LTO in there will be always used only by the same snapshot from the release branch and so should be compatible with the LTO in it. Jakub