On Tue, 2015-07-28 at 08:08 +0000, Long, Qin wrote: > This sounds good. > Where this new-generated opensslconf.h will be placed? In > /openssl/crypto/ or EDKII-package include path? We still need one > script to install / replace this file?
It looks like the tarball releases of OpenSSL contain a version of opensslconf.h — which we were previously patching, for the 1.0.2d and earlier tarballs. So I think it's best for us to drop our pre-prepared version over the top of that one. It's actually in openssl/include/ now instead of openssl/crypto/ — all the header files moved, remember. The instructions will be: - extract tarball - copy opensslconf.h to $(OPENSSL_PATH)/include/openssl/opensslconf.h Unless you want to put it in CryptoPkg/Include/openssl/ and you're *sure* it'll always get included before the tarball's version in $(OPENSSL_PATH)? That would avoid the 'copy' step, but doesn't really fill me with joy... but I suppose we could add something in OpensslSupport.h to #error if the wrong one ever does get included? > > > > > Actually, aren't the only things in OPENSSL_FLAGS now MSFT > > > > > -specific anyway? > > > > I'll leave that question hanging there. In fact I think there's some > > scope for cleaning up all of the cflags definitions at the end of the > > file. > > In fact, it's not MSFT-specific flags in OPENSSL_FLAGS. Isn't it? All we have left is: DEFINE OPENSSL_FLAGS = -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE Can that not be moved to the MSFT compiler flags? I'm fairly sure it doesn't do anything in GCC! :) I'd also quite like to understand the various -U_WIN32 and similar that we have, even for GCC. Was that because we might be building with a MinGW toolchain? And because OpenSSL would do something different and wrong if it saw _WIN32/_WIN32/_MSC_VER defined? I'd like to fix those *properly* in OpenSSL in the case that OPENSSL_SYS_UEFI is defined, rather than having to undefine them on the command line. But again, that's something that can wait until the first pass is done. I'd *also* like to see if we can eliminate some of those compiler warnings. Isn't it rather scary that we have to build the crypto package with various compiler warnings *disabled* because otherwise the build breaks? Think about that for a moment... :) -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
