From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.53791.1598882634345512991 for ; Mon, 31 Aug 2020 07:03:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jI/avZ/J; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598882633; h=from:from: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=v9KUvkTXo98hQg+kGibQIjJT5/QjG5+oKLl/mX7dN4o=; b=jI/avZ/JDpYMEjDoA+F+3GKlV9u6RSLYll1TRSuRJTuQl8kllNJyz+fBidq79qoOOzOWkx ZZIFJN3r6bLR7BlDiZF5BO5wzvHu3ckQKX4i0+9ufV2fbhrlT7C2OqBzG4IZYJzVvomYRo QZzpQxDhSxpyEKSkX0whmiZ9T713DDU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-332-TkOnu9c8NmWj2Z4fYI-3EA-1; Mon, 31 Aug 2020 10:03:49 -0400 X-MC-Unique: TkOnu9c8NmWj2Z4fYI-3EA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 70D7E5708F; Mon, 31 Aug 2020 14:03:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-125.ams2.redhat.com [10.36.113.125]) by smtp.corp.redhat.com (Postfix) with ESMTP id AA7A67DA4D; Mon, 31 Aug 2020 14:03:44 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH V2 2/2] BaseTools: Factorize GCC flags To: Ard Biesheuvel , Leif Lindholm Cc: Pierre Gondois , "devel@edk2.groups.io" , "bob.c.feng@intel.com" , "liming.gao@intel.com" , Tomas Pilar , nd References: <20200707083522.138944-1-pierre.gondois@arm.com> <20200707083522.138944-3-pierre.gondois@arm.com> <879fda8a-37bd-a902-6028-c879ed37fa28@redhat.com> <22b94ad5-db03-7280-4032-6ebf8dfc1d49@redhat.com> <518916e0-53cc-732b-cf1b-1e1b8d10a3b3@redhat.com> <20200827152511.GX1191@vanye> <42cb48da-b932-7006-475b-d5259bcd0d8a@redhat.com> <20200828191515.GC1191@vanye> From: "Laszlo Ersek" Message-ID: Date: Mon, 31 Aug 2020 16:03:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US On 08/31/20 15:22, Ard Biesheuvel wrote: > mainline EDK2 is arguably a development tree I agree. > not a stable production tree for ~5 year old firmware builds I agree with that too. But I don't think GCC48 is "holding back" edk2. I don't know of a firmware feature that suffers because I'd like to be able to build the tree with GCC48. (LTO is not a firmware feature; and NOOPT builds, which are important, don't / shouldn't enable LTO anyway.) I do agree that maintaining the BaseTools stuff that's related to GCC48 is a burden, technically speaking. Is it a big burden? Should I attempt to handle related issues? Official Software Collections / Developer Toolset add-ons exist for RHEL7: https://developers.redhat.com/products/developertoolset/overview https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/9/html/user_guide/chap-red_hat_developer_toolset#sect-Red_Hat_Developer_Toolset-Compatibility I've played with them in the past. They weren't a good fit for me, as I recall. Anyway, I can check them out again, if I must. > and so I do think we should get rid of GCC48 even before RHEL7 goes > EOL. We might want to explore the Debian / Ubuntu status too (LTS). Thanks, Laszlo