From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web10.57161.1598890733610587907 for ; Mon, 31 Aug 2020 09:18:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bJAL40MK; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598890732; 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=jGMQg4AQEGvBpfTM4uazXlayk8o4V26SXSik+E5/7Q8=; b=bJAL40MK3lV+fvs1dpMcUDU6dE9F1OdLsqF/pLN1fkXiDkwsY8HmFqg2B8k+s9uGj0pTVg VlOcca6wP1SZ2sKKajZzRLR1ytucz+oIMU2XjKVD6NZArWH8KkOV8RWCXoge5/yycXipes 5b7G4mznJdtrpSXVtboVxd0lkrTPe4M= 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-532-M_5rj90DMxOG0Frv-PsZUg-1; Mon, 31 Aug 2020 12:18:47 -0400 X-MC-Unique: M_5rj90DMxOG0Frv-PsZUg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4BCE2801AC9; Mon, 31 Aug 2020 16:18: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 8822610013BD; Mon, 31 Aug 2020 16:18: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> <75feab5d-c7c9-972f-4201-0dd6c4280569@arm.com> From: "Laszlo Ersek" Message-ID: <0420cc47-ed41-54b9-b5cf-cf722c40ebfe@redhat.com> Date: Mon, 31 Aug 2020 18:18: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: <75feab5d-c7c9-972f-4201-0dd6c4280569@arm.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US On 08/31/20 16:37, Ard Biesheuvel wrote: > Not sure how Leif feels about this, but i wouldn't mind retaining > GCC48 support only for IA32/X64. I've never considered GCC48 usable for ARM/AARCH64. I already use GCC48 for IA32/X64 only. Anyway... it looks like I am able to consume gcc-9 ("devtoolset-9-gcc-9.3.1-2.el7.x86_64") and compatible binutils ("devtoolset-9-binutils-2.32-16.el7.x86_64"), for building edk2 with the GCC5 toolchain tag on RHEL7. I've done a few tests with OVMF; nothing seems to break. > Agreed. But one final remark on the distro/system toolchain situation: > distros have good reasons for sticking with a single GCC version to > build the world, but I wonder if any of them hold for UEFI builds such > as OVMF, which runs entirely in its own context, and is mangled by > GenFw so the ELF objects are never even consumed directly. So as I see > it, the *only* benefit of retaining GCC48 support is for the > convenience of developers that use 'mature' distros like RHEL 7 and > prefer to use the compiler that happens to be installed. I am not > saying this is not a good enough reason, just something we have to > realize. You're not wrong -- I'd just like to clarify that "prefer" is not always a simple personal choice. Building gcc + binutils from source (and finding the right versions in the first place) is traditionally not one of the easier "I'll just build this for myself" endeavors. (With gcc rebuilding itself several times etc.) Furthermore, given that "devtoolset-9" is a "software collection" (managed by the "scl" cmdline utility) at least in my env, its usage is *really* inconvenient in some circumstances. It modifies a bunch of environment variables (of course), but (AIUI) the recommended / supported end-user interface is to let "scl" start a command or subshell for you. The mode when it outputs a bunch of "export" statements for one's shell to "source" requires gymnastics, and it does not seem officially supported. I find it unfortunate that it wants to become the parent of whatever I'm trying to run. Add in the fact that single-line invocations require unwieldy quoting: """ scl enable example 'less --version' runs command 'less --version' in the environment with collection 'example' enabled scl enable foo bar bash runs bash instance with foo and bar Software Collections enabled """ Obviously the following form would be preferred: scl enable example -- less --version Because this form would not require quoting, just prefixing. Anyway... I've now hacked those scripts of mine that needed hacking, so I guess I'm no longer tied to GCC48 for IA32/X64 either. Thanks, Laszlo