From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: linux.intel.com, ip: 134.134.136.20, mailfrom: ryszard.knop@linux.intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by groups.io with SMTP; Tue, 16 Apr 2019 07:56:10 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2019 07:56:09 -0700 X-IronPort-AV: E=Sophos;i="5.60,358,1549958400"; d="scan'208";a="224021811" Received: from rknop-mobl.ger.corp.intel.com (HELO [10.102.8.30]) ([10.102.8.30]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES128-SHA; 16 Apr 2019 07:56:09 -0700 From: "Ryszard Knop" Subject: Building current OVMF master with multiple workspaces on Windows/VS2017 fails due to missing includes? To: devel@edk2.groups.io Message-ID: Date: Tue, 16 Apr 2019 16:56:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:67.0) Gecko/20100101 Thunderbird/67.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US I have a bit odd issues with building OVMF from the current master branch (commit 0eccea3...), with the following setup using multiple workspaces (this is important): - Windows 10, 64-bit - Visual Studio 2017 build tools (conf'd with VS2017_PREFIX envvar) - NASM 2.14.02 (conf'd with NASM_PREFIX envvar) - Python 3.7.3 running the latest BaseTools - WORKSPACE envvar points at a dir with extra modules to be included with OVMF (C:\Env\OvmfBuild) - PACKAGES_PATH points at the EDK2 repo (C:\Env\Workspace\edk2) All envvars are set before edksetup. Trying to build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -b RELEASE -t VS2017 fails with the following: "C:\Env\BuildTools\MSVS2017_SDK_WDK_Windows10_16299\Program Files\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\Hostx86\x64\cl.exe" /nologo /E /TC /FIAutoGen.h /IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64 /IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib /Ic:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\DEBUG /IC:\Env\Workspace\edk2\MdePkg /IC:\Env\Workspace\edk2\MdePkg\Include /IC:\Env\Workspace\edk2\MdePkg\Include\X64 C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm > c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i LongJump.nasm         Trim --trim-long --source-code -o c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i         "C:\Env\BuildTools\NASM\2.14.02\nasm" -IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\ -Ox -f win64 -o c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.obj c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii:16: fatal: unable to open include file `Nasm.inc' NMAKE : fatal error U1077: 'C:\Env\BuildTools\NASM\2.14.02\nasm.EXE' : return code '0x1' Missing Nasm.inc, which is present in MdePkg/Include/X64/Nasm.inc - but the weird thing is, adding extra NASM include paths was added recently (in BaseTools/Source/Python/AutoGen/GenMake.py there's a block that replaces NASM_INC with appropriate directories, build_rule.template should generate NASM calls with these, as of commit 7c3a1ef). After adding a few prints to the GenMake I can see it does find the proper include paths, but none of them land in the final NASM call in the Makefile, even though it knows about the Nasm.inc dependency - the NASM_INC macro seems to be completely missing from the generated Makefile: $(OUTPUT_DIR)\X64\LongJump.obj : $(MAKE_FILE) $(OUTPUT_DIR)\X64\LongJump.obj : C:\Env\Workspace\edk2\MdePkg\Include\Base.h $(OUTPUT_DIR)\X64\LongJump.obj : C:\Env\Workspace\edk2\MdePkg\Include\X64\Nasm.inc $(OUTPUT_DIR)\X64\LongJump.obj : $(DEBUG_DIR)\AutoGen.h $(OUTPUT_DIR)\X64\LongJump.obj : C:\Env\Workspace\edk2\MdePkg\Include\X64\ProcessorBind.h $(OUTPUT_DIR)\X64\LongJump.obj : C:\Env\Workspace\edk2\MdePkg\Include\Library\PcdLib.h $(OUTPUT_DIR)\X64\LongJump.obj : C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm     "$(PP)" $(PP_FLAGS) $(INC) C:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\LongJump.nasm > c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i     Trim --trim-long --source-code -o c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.i     "$(NASM)" -IC:\Env\Workspace\edk2\MdePkg\Library\BaseLib\X64\ $(NASM_FLAGS) -o c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.obj c:\Env\OvmfBuild\Build\OvmfX64\RELEASE_VS2017\X64\MdePkg\Library\BaseLib\BaseLib\OUTPUT\X64\LongJump.iii The nasty workaround is to copy Nasm.inc into MdePkg/Library/BaseLib/X64 and everything builds just fine after that. Another interesting thing is that if I don't use WORKSPACE and PACKAGES_PATH (both contain no spaces and are on local file systems) but rather build everything directly in the EDK2 directory, OVMF also builds fine (Makefile contains the NASM_INC definition which is included in NASM calls). Have anyone also hit this issue? Thanks, Richard