0 г., в 09:56, Gao, Liming <mailto:liming@intel.com>> написал(а):
>
> Vitaly:
> Yes. I think we should have better solution in OpenSSL to support EDK2
> usage. But, this is a long term solution. For now, I will try the solution to
> remove -fms-compatibility option
y 6, 2020 8:17 AM
To: Gao, Liming
Cc: devel@edk2.groups.io; Marvin Häuser ; Laszlo
Ersek ; Kinney, Michael D
Subject: Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler
Liming,
We performed the initial exploration of CLANGPDB toolchain issue on our end and
believe we can sugges
B tool chain. ThanksLimingFrom: vit9696 <vit9...@protonmail.com> Sent: Monday, February 3, 2020 7:29 PMTo: Gao, Liming <liming@intel.com>; devel@edk2.groups.io; Marvin Häuser <marvin.haeu...@outlook.com>Subject: RE: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler
, Liming ; devel@edk2.groups.io; Marvin Häuser
Subject: RE: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler
Liming,
I believe it is reasonable to fix OpenSSL, but most likely it is faster to
address EDK II code at first. In future we should still stick to _MSC_VER, but
for now
Liming,
I believe it is reasonable to fix OpenSSL, but most likely it is faster to
address EDK II code at first. In future we should still stick to _MSC_VER, but
for now just ensuring that any toolchain by MSVC does not define
_MSC_EXTENSIONS should work too.
I believe that -fms-compatibility
Vitaly:
This change will cause CryptoPkg openssl build failure, because
OpensslLib.inf undefines _MSC_VER macro to make sure openssl source code be
built in edk2 project without using MS VS functions.
Now, I have no good solution to fix this issue. One way is to use
defined(_MSC_EXTENSIONS)
