From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.16298.1661160646557313333 for ; Mon, 22 Aug 2022 02:30:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lF3X+wYM; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CBFED60F4A for ; Mon, 22 Aug 2022 09:30:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A45EC433C1 for ; Mon, 22 Aug 2022 09:30:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661160645; bh=wtsW7fr4GbOn/62jD2DweSvvj6tmM7gc4oetgiPcnlU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lF3X+wYM8GnVrO2OOtzTGOsjSDgsefg7oZSY/CivlQGsa4VhKJbLluDxXlvmOtn4/ ZW6huLDRkS42VDYBQ8okFMnGi5+NvJNf1ZU5cD8NGhN3AgdLs++TQWX9I7hwhkI1S3 0TOFf8n/VaJZ7Id+/ybd+LTsuIfkknuYM1RTu7CRDWdEopiNkX8NN+sfB86gzkkWMj nS9NbeVicn9Z7TQv3DVT0oM8im0rUPAyGSx42Ckboxyp6zfsjyH1EAg+/15i96WyVx LqJfYNlKxMCE3tS2MvEr5odLpVShQsLLxN+9C9BOP6Mnd0sO1Oj3pNM237qzX7K15R /yZUr3i5brpnA== Received: by mail-wm1-f54.google.com with SMTP id j26so5271411wms.0 for ; Mon, 22 Aug 2022 02:30:45 -0700 (PDT) X-Gm-Message-State: ACgBeo098bAeKAr8IaakutY3G/AKOCrXtggE1vuDOLccTPCoEJ5Hb+PY EP6VmnPE1sYZNx6HuCiOV8AQXpfxdA7OTj0caJY= X-Google-Smtp-Source: AA6agR5vR0JzxPlcG5/edn9yp0WLt3I7z8OZn0zv94vpCMiDS2duf7DJHUJ7SInSF9p12EM7wlPWocSdPa5aS1fFgss= X-Received: by 2002:a05:600c:384f:b0:3a6:603c:4338 with SMTP id s15-20020a05600c384f00b003a6603c4338mr3357555wmr.192.1661160643382; Mon, 22 Aug 2022 02:30:43 -0700 (PDT) MIME-Version: 1.0 References: <41a26d57-4fae-f53f-29ae-d6c7b258eaee@bsdio.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 22 Aug 2022 11:30:32 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] MdeModulePkg build fails for AARCH64 on Ubuntu 22.04 To: devel@edk2.groups.io, rebecca@bsdio.com, "Feng, Bob C" , Liming Gao Cc: Andrew Fish , Leif Lindholm , Michael D Kinney , Jian J Wang Content-Type: text/plain; charset="UTF-8" On Mon, 22 Aug 2022 at 11:11, Ard Biesheuvel wrote: > > (cc Bob) > > NOTE this affects the stable tag - please see below > > > On Sun, 21 Aug 2022 at 06:34, Rebecca Cran wrote: > > > > I noticed that MdeModulePkg fails to build on my Ubuntu 22.04 system > > (and previously on the Ubuntu 20.04 installation). Is this a known bug? > > > > It shouldn't be relevant, but I'm using gcc version 11.2.0 (Ubuntu > > 11.2.0-17ubuntu1). But perhaps more relevant, I'm using Python 3.10.4. > > > > I'm trying to build commit e2ac68a23b4954d5c0399913a1df3dd9fd90315d. > > > > > > bcran@photon:~/src/tmp/edk2$ build -p MdeModulePkg/MdeModulePkg.dsc -a > > AARCH64 -t GCC5 -b RELEASE > > Build environment: Linux-5.15.0-46-generic-x86_64-with-glibc2.35 > > Build start time: 22:29:18, Aug.20 2022 > > > > WORKSPACE = /home/bcran/src/tmp/edk2 > > EDK_TOOLS_PATH = /home/bcran/src/tmp/edk2/BaseTools > > CONF_PATH = /home/bcran/src/tmp/edk2/Conf > > PYTHON_COMMAND = /usr/bin/python3 > > > > > > Processing meta-data > > .Architecture(s) = AARCH64 > > Build target = RELEASE > > Toolchain = GCC5 > > > > Active Platform = > > /home/bcran/src/tmp/edk2/MdeModulePkg/MdeModulePkg.dsc > > > > > > build.py... > > /home/bcran/src/tmp/edk2/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf(42): > > error 3000: PCD > > [gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode] in > > [/home/bcran/src/tmp/edk2/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf] > > is not found in dependent packages: > > /home/bcran/src/tmp/edk2/MdePkg/MdePkg.dec > > /home/bcran/src/tmp/edk2/MdeModulePkg/MdeModulePkg.dec > > > > > > This looks like a BaseTools regression to me - afaik, these packages > all used to build for AARCH64 in the past. > > The following LockBoxLib resolutions appear in MdeModulePkg.dsc (with > line numbers) > > 115-[LibraryClasses.common.PEIM] > 119: LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf > > 178-[LibraryClasses.ARM, LibraryClasses.AARCH64] > 181: LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf > > No other [LlibraryClasses] references to SmmLockBoxPeiLib.inf exist in > that file, and the [Components] reference does not apply to AARCH64. > > This means the DSC parser ends up using the earlier definition, which > I think is a bug, or at least a change in behavior. Note that doing > this silently could potentially break many platforms in subtle ways so > I think this should be root caused and preferably fixed before > creating the stable tag. Seems to be deliberate: commit 039bdb4d3e96f9c9264abf135b8a0eef2e2b4860 Author: Chen, Christine Date: Thu Jun 30 17:04:05 2022 +0800 BaseTools: Fix DSC LibraryClass precedence rule but I don't think the impact on other platforms and drivers has been taken into account here. Also, the document [0] seems ambiguous to me: """ The first globally defined library instance, defined in a DSC file, that satisfies a module's requirement for a Library Class, unless specifically overridden by the module in the [Components] section, will be used. """ This says that the first occurrence of a library instance definition that satisfies a INF dependency will be selected. Then, there is """ The Library Instances will be selected using the following rules to satisfy a library class for each module listed in the [Components] section (in order of highest precedence): """ which says that not the *first* occurrence, but the occurrence *with the highest precedence* will be selected. Then, the precedence list has these items: """ 2. [LibraryClasses.$(Arch).$(MODULE_TYPE), LibraryClasses.$(Arch).$(MODULE_TYPE)] 3. [LibraryClasses.$(Arch).$(MODULE_TYPE)] """ which seem to suggest that a definition that applies to multiple arch/module_type combinations automatically takes precedence over one that targets a single arch/module_type combination, which makes no sense at all. So I strongly suggest we revert the patch, fix the document so it is clear and ambiguous, and preferably, align it with how it used to work. [0] https://edk2-docs.gitbook.io/edk-ii-dsc-specification/2_dsc_overview/26_-libraryclasses-_section_processing