From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.51318.1681729427680226421 for ; Mon, 17 Apr 2023 04:03:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FMwf7nI+; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681729426; 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: in-reply-to:in-reply-to:references:references; bh=oNIm6vt/6SyonmT9nO2nVgIaoLZBLGI0TzzS6Arqsus=; b=FMwf7nI+DyIhu7Ku4oyWE7eHZnMpuVg3e0A6srVODY65HeO49MvYyEdWfYA6eN4JbDchF0 3tK1cQt1Y0h6pwkeUs4I3ZFzeFrpEnCwyw9ybc1jpbMLeDvdqg22fNi8hHS5kurDfxGG+m 8vuq50QMVISdA1LUH9qNivCQ/+sCvW4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-240-pjG2O0ZANt-znBl-MQzJ0w-1; Mon, 17 Apr 2023 07:03:41 -0400 X-MC-Unique: pjG2O0ZANt-znBl-MQzJ0w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E6587855312; Mon, 17 Apr 2023 11:03:39 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6161240C20FA; Mon, 17 Apr 2023 11:03:39 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 8726E18000B3; Mon, 17 Apr 2023 13:03:37 +0200 (CEST) Date: Mon, 17 Apr 2023 13:03:37 +0200 From: "Gerd Hoffmann" To: Rebecca Cran Cc: devel@edk2.groups.io, Liming Gao , Bob Feng , Yuwei Chen , Michael D Kinney , Michael Kubacki , Sean Brogan , Chasel Chiu , Nate DeSimone , Star Zeng , Andrew Fish , Ray Ni , Leif Lindholm , Zhiguang Liu , Jian J Wang , Xiaoyu Lu , Guomin Jiang , Gua Guo , Ard Biesheuvel , Pedro Falcato , Marvin =?utf-8?Q?H=C3=A4user?= Subject: Re: [PATCH v3 09/13] BaseTools/Conf/tools_def.template: Add GCC and GCCNOLTO toolchains Message-ID: References: <20230416170532.278338-1-rebecca@bsdio.com> <20230416170532.278338-10-rebecca@bsdio.com> MIME-Version: 1.0 In-Reply-To: <20230416170532.278338-10-rebecca@bsdio.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > +DEFINE GCCNOLTO_IA32_PREFIX = ENV(GCCNOLTO_BIN) > +DEFINE GCCNOLTO_X64_PREFIX = ENV(GCCNOLTO_BIN) > + > DEFINE GCC5_IA32_PREFIX = ENV(GCC5_BIN) > DEFINE GCC5_X64_PREFIX = ENV(GCC5_BIN) > +DEFINE GCC_IA32_PREFIX = ENV(GCC_BIN) > +DEFINE GCC_X64_PREFIX = ENV(GCC_BIN) Does it make sense to have a separate prefix for each gcc variant? I guess it makes sense for the existing GCC5 and GCC4x configs for backward compatibility reasons, but for the new GCC / GCCNOLTO variants not so much. Trying to build ia32 ovmf with clang (15) and openssl fails btw: ld.lld: error: undefined symbol: __lshrdi3 But I guess that isn't something new introduced by this series. take care, Gerd