Build fails with VS2012


Rebecca Cran
 

I'm setting up a new Jenkins server to do Bhyve builds and run on platforms that aren't currently tested with the GitHub/Azure system.

Since VS2012 appears to be a supported toolchain, I tried building OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017 and VS2019), but it fails with:


Building ... c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf [X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268) : error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268) : warning C4306: 'type cast' : conversion from 'int' to 'SEV_ES_AP_JMP_FAR *' of greater size

I know the GitHub/Azure system only tests with VS2017 and VS2019: are there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or should they be considered unsupported?

--
Rebecca Cran


Rebecca Cran
 

Similarly the build is also failing with GCC49, using gcc 4.9.2:

/edk2/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c: In function 'ShellSortFileList':
Building ... /edk2/OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf [X64]
/edk2/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c:2202:19: error: 'Dupes' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*Duplicates = Dupes;
^


--
Rebecca Cran

On 5/8/21 1:47 PM, Rebecca Cran wrote:
I'm setting up a new Jenkins server to do Bhyve builds and run on platforms that aren't currently tested with the GitHub/Azure system.
Since VS2012 appears to be a supported toolchain, I tried building OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017 and VS2019), but it fails with:
Building ... c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf [X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268) : error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268) : warning C4306: 'type cast' : conversion from 'int' to 'SEV_ES_AP_JMP_FAR *' of greater size
I know the GitHub/Azure system only tests with VS2017 and VS2019: are there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or should they be considered unsupported?


Laszlo Ersek
 

Hi Rebecca

+Tom

On 05/08/21 21:47, Rebecca Cran wrote:
I'm setting up a new Jenkins server to do Bhyve builds and run on
platforms that aren't currently tested with the GitHub/Azure system.

Since VS2012 appears to be a supported toolchain, I tried building
OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017
and VS2019), but it fails with:


Building ...
c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf
[X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: warning C4306: 'type cast' : conversion from 'int' to
'SEV_ES_AP_JMP_FAR *' of greater size
I think the compiler is justified to complain here:

7b7508ad784d1 (Tom Lendacky 2020-08-12 15:21:42 -0500 1268) JmpFar = (SEV_ES_AP_JMP_FAR *) FixedPcdGet32 (PcdSevEsWorkAreaBase);

The proper way to spell such casts is with (UINTN) in the middle.

Can you please file a new BZ?

I know the GitHub/Azure system only tests with VS2017 and VS2019: are
there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or
should they be considered unsupported?
I'd suggest dropping them.

Earlier, Ard raised a similar question for gcc too -- IIRC, Ard suggested that GCC4* be removed. I agree with the idea.

Thanks
Laszlo


Laszlo Ersek
 

On 05/09/21 19:42, Rebecca Cran wrote:
Similarly the build is also failing with GCC49, using gcc 4.9.2:

/edk2/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c: In
function 'ShellSortFileList':
Building ...
/edk2/OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf [X64]
/edk2/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c:2202:19: error:
'Dupes' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
       *Duplicates = Dupes;
                   ^

This was reported earlier in:

https://bugzilla.tianocore.org/show_bug.cgi?id=3228

and Sergei proposed a patch for nulling "Dupes" (among other things) in
an attachment on that BZ.

See my feedback in <https://bugzilla.tianocore.org/show_bug.cgi?id=3228#c6>.

Thanks
Laszlo


Rebecca Cran
 

On 5/10/21 5:56 AM, Laszlo Ersek wrote:
Hi Rebecca
+Tom
On 05/08/21 21:47, Rebecca Cran wrote:
I'm setting up a new Jenkins server to do Bhyve builds and run on
platforms that aren't currently tested with the GitHub/Azure system.

Since VS2012 appears to be a supported toolchain, I tried building
OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017
and VS2019), but it fails with:


Building ...
c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf
[X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: warning C4306: 'type cast' : conversion from 'int' to
'SEV_ES_AP_JMP_FAR *' of greater size
I think the compiler is justified to complain here:
7b7508ad784d1 (Tom Lendacky 2020-08-12 15:21:42 -0500 1268) JmpFar = (SEV_ES_AP_JMP_FAR *) FixedPcdGet32 (PcdSevEsWorkAreaBase);
The proper way to spell such casts is with (UINTN) in the middle.
Can you please file a new BZ?
I've created https://bugzilla.tianocore.org/show_bug.cgi?id=3385

I know the GitHub/Azure system only tests with VS2017 and VS2019: are
there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or
should they be considered unsupported?
I'd suggest dropping them.
Earlier, Ard raised a similar question for gcc too -- IIRC, Ard suggested that GCC4* be removed. I agree with the idea.
Thanks. If we're ready to go ahead, should I create a patch to remove them?

Do you know what the new minimum version of gcc should then be? I'd like to run builds with it so we can catch any issues.

Would we remove all VS versions except VS2017 and VS2019, or would we keep others like VS2015 for now?

--
Rebecca Cran


Michael D Kinney
 

I think there a few categories of tool chains:

1) Tool chains that are in tools_def.txt and are used by EDK II CI to perform pre-commit and post-commit changes. These are documented in Readme.rst
2) Tool chains that are in tools_def.txt that are fully supported by the EDK II community. Should be documented in Readme.rst.
3) Tool chains that are in tools_def.txt, but are not supported by the EDK II community, but some downstream consumers use the tool chain are willing to fix issues that impact them.
4) Tool chains that are in tools_def.txt, but are not used by anyone.

We need to make sure we document (1), (2), and (3) so we can identify and delete (4) from tools_def.txt.

Thanks,

Mike

-----Original Message-----
From: Rebecca Cran <rebecca@nuviainc.com>
Sent: Monday, May 10, 2021 6:21 AM
To: devel@edk2.groups.io; lersek@redhat.com; rebecca@bsdio.com
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] Build fails with VS2012

On 5/10/21 5:56 AM, Laszlo Ersek wrote:
Hi Rebecca

+Tom

On 05/08/21 21:47, Rebecca Cran wrote:
I'm setting up a new Jenkins server to do Bhyve builds and run on
platforms that aren't currently tested with the GitHub/Azure system.

Since VS2012 appears to be a supported toolchain, I tried building
OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017
and VS2019), but it fails with:


Building ...
c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf
[X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: warning C4306: 'type cast' : conversion from 'int' to
'SEV_ES_AP_JMP_FAR *' of greater size
I think the compiler is justified to complain here:

7b7508ad784d1 (Tom Lendacky 2020-08-12 15:21:42 -0500 1268) JmpFar = (SEV_ES_AP_JMP_FAR *) FixedPcdGet32
(PcdSevEsWorkAreaBase);

The proper way to spell such casts is with (UINTN) in the middle.

Can you please file a new BZ?
I've created https://bugzilla.tianocore.org/show_bug.cgi?id=3385

I know the GitHub/Azure system only tests with VS2017 and VS2019: are
there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or
should they be considered unsupported?
I'd suggest dropping them.

Earlier, Ard raised a similar question for gcc too -- IIRC, Ard suggested that GCC4* be removed. I agree with the idea.
Thanks. If we're ready to go ahead, should I create a patch to remove them?

Do you know what the new minimum version of gcc should then be? I'd like
to run builds with it so we can catch any issues.

Would we remove all VS versions except VS2017 and VS2019, or would we
keep others like VS2015 for now?

--
Rebecca Cran


Rebecca Cran
 

Thanks. The obvious toolchains that are missing from ReadMe.rst are any versions of XCODE and CLANG.
Also, it might be nice to specify _which_ GCC5 versions are supported, since that covers gcc 5 through 11 and gcc 5.x currently causes a build error. We maybe only care about gcc 7 and newer these days?

I just tried building with VS2015 and VS2013, and there was a build error because it seems the location of rc.exe has changed. After fixing that they successfully built OVMF. But it sounds like we possibly only want to make sure that VS2017 and VS2019 are kept working now.

I've cc'd Bret and Sean because I'm wondering if there are plans to add more toolchain/OS combinations into the GitHub/Azure solution? For example adding macOS with XCODE5? Also, how about post-commit or nightly builds that run more extensive tests, possibly generating binaries for OVMF that people can try without building it themselves? Or would that be something that might be useful for me to implement as a third-party solution?

--
Rebecca Cran

On 5/10/21 5:31 PM, Michael D Kinney wrote:
I think there a few categories of tool chains:
1) Tool chains that are in tools_def.txt and are used by EDK II CI to perform pre-commit and post-commit changes. These are documented in Readme.rst
2) Tool chains that are in tools_def.txt that are fully supported by the EDK II community. Should be documented in Readme.rst.
3) Tool chains that are in tools_def.txt, but are not supported by the EDK II community, but some downstream consumers use the tool chain are willing to fix issues that impact them.
4) Tool chains that are in tools_def.txt, but are not used by anyone.
We need to make sure we document (1), (2), and (3) so we can identify and delete (4) from tools_def.txt.
Thanks,
Mike

-----Original Message-----
From: Rebecca Cran <rebecca@nuviainc.com>
Sent: Monday, May 10, 2021 6:21 AM
To: devel@edk2.groups.io; lersek@redhat.com; rebecca@bsdio.com
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] Build fails with VS2012

On 5/10/21 5:56 AM, Laszlo Ersek wrote:
Hi Rebecca

+Tom

On 05/08/21 21:47, Rebecca Cran wrote:
I'm setting up a new Jenkins server to do Bhyve builds and run on
platforms that aren't currently tested with the GitHub/Azure system.

Since VS2012 appears to be a supported toolchain, I tried building
OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017
and VS2019), but it fails with:


Building ...
c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf
[X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: warning C4306: 'type cast' : conversion from 'int' to
'SEV_ES_AP_JMP_FAR *' of greater size
I think the compiler is justified to complain here:

7b7508ad784d1 (Tom Lendacky 2020-08-12 15:21:42 -0500 1268) JmpFar = (SEV_ES_AP_JMP_FAR *) FixedPcdGet32
(PcdSevEsWorkAreaBase);

The proper way to spell such casts is with (UINTN) in the middle.

Can you please file a new BZ?
I've created https://bugzilla.tianocore.org/show_bug.cgi?id=3385

I know the GitHub/Azure system only tests with VS2017 and VS2019: are
there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or
should they be considered unsupported?
I'd suggest dropping them.

Earlier, Ard raised a similar question for gcc too -- IIRC, Ard suggested that GCC4* be removed. I agree with the idea.
Thanks. If we're ready to go ahead, should I create a patch to remove them?

Do you know what the new minimum version of gcc should then be? I'd like
to run builds with it so we can catch any issues.

Would we remove all VS versions except VS2017 and VS2019, or would we
keep others like VS2015 for now?

--
Rebecca Cran


Laszlo Ersek
 

On 05/11/21 02:14, Rebecca Cran wrote:
Thanks. The obvious toolchains that are missing from ReadMe.rst are any
versions of XCODE and CLANG.
Also, it might be nice to specify _which_ GCC5 versions are supported,
since that covers gcc 5 through 11 and gcc 5.x currently causes a build
error. We maybe only care about gcc 7 and newer these days?

I just tried building with VS2015 and VS2013, and there was a build
error because it seems the location of rc.exe has changed. After fixing
that they successfully built OVMF. But it sounds like we possibly only
want to make sure that VS2017 and VS2019 are kept working now.

I've cc'd Bret and Sean because I'm wondering if there are plans to add
more toolchain/OS combinations into the GitHub/Azure solution? For
example adding macOS with XCODE5? Also, how about post-commit or nightly
builds that run more extensive tests, possibly generating binaries for
OVMF that people can try without building it themselves? Or would that
be something that might be useful for me to implement as a third-party
solution?
Too many good questions!

Personally, I care for gcc-8, and later.

Thanks
Laszlo


Andrew Fish
 

I’m always happy to resolve any Xcode issues. 

Thanks,

Andrew Fish

On May 11, 2021, at 7:41 AM, Laszlo Ersek <lersek@...> wrote:

On 05/11/21 02:14, Rebecca Cran wrote:
Thanks. The obvious toolchains that are missing from ReadMe.rst are any
versions of XCODE and CLANG.
Also, it might be nice to specify _which_ GCC5 versions are supported,
since that covers gcc 5 through 11 and gcc 5.x currently causes a build
error. We maybe only care about gcc 7 and newer these days?

I just tried building with VS2015 and VS2013, and there was a build
error because it seems the location of rc.exe has changed. After fixing
that they successfully built OVMF. But it sounds like we possibly only
want to make sure that VS2017 and VS2019 are kept working now.

I've cc'd Bret and Sean because I'm wondering if there are plans to add
more toolchain/OS combinations into the GitHub/Azure solution? For
example adding macOS with XCODE5? Also, how about post-commit or nightly
builds that run more extensive tests, possibly generating binaries for
OVMF that people can try without building it themselves? Or would that
be something that might be useful for me to implement as a third-party
solution?


Too many good questions!

Personally, I care for gcc-8, and later.

Thanks
Laszlo