[openssl] update to 3.0.2

[Thomas1664]

Describe the pull request This PR updates openssl to version 3.0.2. ~~The consensus is to update openssl and to create a new port called openssl1 for future updates to openssl 1.1.1. No port depends or should ever depend on openssl1. All ports that were incompatible to OpenSSL 3 were updated or patched.~~

See below.

• What does your PR fix?

  Fixes #20031

• Which triplets are supported/not supported? Have you updated the CI baseline?

  Yes, skip openssl1 on all triplets

• Does your PR follow the maintainer guide?

  Yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  Yes

[ghost]

All CLA requirements met.

[ras0219-msft]

Thanks for this PR!

Please change this to upgrade the existing openssl port in place; see the discussion as part of https://github.com/microsoft/vcpkg/issues/20031.

[Thomas1664]

Seems like the URL to "https://www.openssl.org/source/3.0.1/openssl-${OPENSSL_VERSION}.tar.gz" is not stable as it will change to "https://www.openssl.org/source/OLD/3.0.1/openssl-${OPENSSL_VERSION}.tar.gz" if additional versions will be released. Should I remove this URL or should I keep it for now?

Update: In fact, both of these URLs don't work. I had to remove them.

[Thomas1664]

I was able to fix all CI issues except for those on UWP. They still fail with the following error: @ras0219-msft What are these logs trying to tell me and how to fix it? BTW: CI running for > 2 hours (as time of writing this)

2022-02-01T15:23:58.8318113Z -- Downloading https://www.openssl.org/source/openssl-3.0.1.tar.gz -> openssl-3.0.1.tar.gz...
2022-02-01T15:23:59.1837231Z -- Downloading https://strawberryperl.com/download/5.32.1.1/strawberry-perl-5.32.1.1-32bit.zip -> strawberry-perl-5.32.1.1-32bit.zip...
2022-02-01T15:24:04.6547465Z -- Downloading https://download.qt.io/official_releases/jom/jom_1_1_3.zip;https://mirrors.ocf.berkeley.edu/qt/official_releases/jom/jom_1_1_3.zip -> jom_1_1_3.zip...
2022-02-01T15:24:05.0570883Z -- Extracting source D:/downloads/openssl-3.0.1.tar.gz
2022-02-01T15:24:05.7822147Z -- Applying patch uwp/EnableUWPSupport.patch
2022-02-01T15:24:05.7975604Z CMake Error at scripts/cmake/z_vcpkg_apply_patches.cmake:61 (message):
2022-02-01T15:24:05.7981793Z   Applying patch failed: Checking patch Configurations/10-main.conf...
2022-02-01T15:24:05.7984635Z 
2022-02-01T15:24:05.7990829Z   error: while searching for:
2022-02-01T15:24:05.7993704Z 
2022-02-01T15:24:05.7999688Z       },
2022-02-01T15:24:05.8005603Z       "VC-WIN64I" => {
2022-02-01T15:24:05.8011562Z           inherit_from     => [ "VC-WIN64-common", asm("ia64_asm"),
2022-02-01T15:24:05.8017453Z                                 sub { $disabled{shared} ? () : "ia64_uplink" } ],
2022-02-01T15:24:05.8023290Z           AS               => "ias",
2022-02-01T15:24:05.8029181Z           ASFLAGS          => "-d debug",
2022-02-01T15:24:05.8035061Z           asoutflag        => "-o ",
2022-02-01T15:24:05.8037872Z 
2022-02-01T15:24:05.8043848Z   
2022-02-01T15:24:05.8046698Z 
2022-02-01T15:24:05.8052771Z   error: patch failed: Configurations/10-main.conf:1287
2022-02-01T15:24:05.8055497Z 
2022-02-01T15:24:05.8061636Z   error: Configurations/10-main.conf: patch does not apply
2022-02-01T15:24:05.8064379Z 
2022-02-01T15:24:05.8070487Z   Checking patch Configurations/50-win-onecore.conf...
2022-02-01T15:24:05.8073267Z 
2022-02-01T15:24:05.8079282Z   error: while searching for:
2022-02-01T15:24:05.8082067Z 
2022-02-01T15:24:05.8088082Z   # Windows OneCore targets.
2022-02-01T15:24:05.8090971Z 
2022-02-01T15:24:05.8096984Z   #
2022-02-01T15:24:05.8099830Z 
2022-02-01T15:24:05.8105917Z   # OneCore is new API stability "contract" that transcends Desktop, IoT and
2022-02-01T15:24:05.8108618Z 
2022-02-01T15:24:05.8114566Z   
2022-02-01T15:24:05.8117391Z 
2022-02-01T15:24:05.8123956Z   error: patch failed: Configurations/50-win-onecore.conf:1
2022-02-01T15:24:05.8126694Z 
2022-02-01T15:24:05.8132755Z   error: Configurations/50-win-onecore.conf: patch does not apply
2022-02-01T15:24:05.8135492Z 
2022-02-01T15:24:05.8141566Z   Checking patch Configure...
2022-02-01T15:24:05.8144443Z 
2022-02-01T15:24:05.8150462Z   warning: Configure has type 100644, expected 100755
2022-02-01T15:24:05.8153213Z 
2022-02-01T15:24:05.8159178Z   error: while searching for:
2022-02-01T15:24:05.8161949Z 
2022-02-01T15:24:05.8167926Z       "ubsan",
2022-02-01T15:24:05.8173812Z       "ui-console",
2022-02-01T15:24:05.8179713Z       "unit-test",
2022-02-01T15:24:05.8186156Z       "whirlpool",
2022-02-01T15:24:05.8192132Z       "weak-ssl-ciphers",
2022-02-01T15:24:05.8197642Z       "zlib",
2022-02-01T15:24:05.8200387Z 
2022-02-01T15:24:05.8206359Z   
2022-02-01T15:24:05.8209188Z 
2022-02-01T15:24:05.8215256Z   error: patch failed: Configure:407
2022-02-01T15:24:05.8218006Z 
2022-02-01T15:24:05.8224061Z   error: Configure: patch does not apply
2022-02-01T15:24:05.8226833Z 
2022-02-01T15:24:05.8232853Z   Checking patch INSTALL...
2022-02-01T15:24:05.8235659Z 
2022-02-01T15:24:05.8241701Z   error: INSTALL: No such file or directory
2022-02-01T15:24:05.8244485Z 
2022-02-01T15:24:05.8251637Z Call Stack (most recent call first):
2022-02-01T15:24:05.8257517Z   scripts/cmake/vcpkg_extract_source_archive.cmake:230 (z_vcpkg_apply_patches)
2022-02-01T15:24:05.8263512Z   scripts/cmake/vcpkg_extract_source_archive_ex.cmake:32 (vcpkg_extract_source_archive)
2022-02-01T15:24:05.8269430Z   ports/openssl/uwp/portfile.cmake:10 (vcpkg_extract_source_archive_ex)
2022-02-01T15:24:05.8275348Z   ports/openssl/portfile.cmake:18 (include)
2022-02-01T15:24:05.8281336Z   scripts/ports.cmake:145 (include)
2022-02-01T15:24:05.8284114Z 
2022-02-01T15:24:05.8287134Z 
2022-02-01T15:24:06.0252171Z Error: Building package openssl:arm-uwp failed with: BUILD_FAILED```

[ras0219-msft]

Yes, unfortunately openssl is widely used so any change tends to rebuild the world so CI will unfortunately be slow.

This log is indicating that the patch for UWP support1 is no longer able to apply to the source code because it changed too much for the tools to match. I'll take a look at the openssl source and come back with next steps.

[ras0219-msft]

It looks like the patch may no longer be required, as openssl has official guidance1 for building on UWP. Could you try removing the patch and applying the build suggestions?

[Thomas1664]

@ras0219-msft Build fails for ~10 packages. Is it sufficient to change their openssl version to the previous one?

[Thomas1664]

UWP builds working fine! All other ports that depend on openssl and where build fails have the issue: Command failed: D:/downloads/tools/cmake-3.21.1-windows/cmake-3.21.1-windows-i386/bin/cmake.exe --build . --config Debug --target install -- -v -j33

Seems like they are incompatible with openssl 3.0.1

OSX:

• libmysql ✔
• librabbitmq ✔
• freerdp ✔
• uthenticode ✔
• boinc ✔
• wangle ✔

x64_uwp:

• libu2f-server ✔
• librtmp ✔
• open62541 ✔
• libdatachannel ✔
• librabbitmq ✔
• libssh2 ✔

arm_uwp:

• libdatachannel: C4996 ✔
• libssh2: C4996 ✔
• open62541: C2220 + C4090 (warnings about different const qualifiers as error) ✔
• librtmp: C4996 ✔
• librabbitmq ✔

x64_linux:

• open62541 ✔
• qpid-proton ✔
• libmysql ✔
• uthenticode ✔
• azure-c-shared-utility ✔
• wangle ✔
• boinc ✔
• aws-sdk-cpp ✔

x64_windows

• libwebsockets ✔
• luasec ✔
• open62541 ✔
• uthenticode ✔
• boinc ✔
• idevicerestore ✔
• freerdp ✔
• librabbitmq ✔
• libfido2 ✔
• libmysql ✔

x64_windows_static

• boinc ✔
• uthenticode ✔
• open62541 ✔
• freerdp ✔
• libwebsockets ✔
• libfido2 ✔
• libmysql ✔

x64_windows_static_md

• libfido2 ✔
• luasec ✔ (luasec doesn't support static)
• uthenticode ✔
• libwebsockets ✔
• boinc ✔
• libmysql ✔
• freerdp ✔

arm64_windows

• librabbitmq ✔
• libwebsockets ✔
• open62541 ✔
• uthenticode ✔
• luasec ✔

x86_windows

• boinc ✔
• libwebsockets ✔
• luasec ✔
• open62541 ✔
• idevicerestore ✔
• librabbitmq ✔
• freerdp ✔
• uthenticode ✔
• libfido2 ✔

[Thomas1664]

@JonLiu1993 Some packages that depend on openssl fail to build with version 3.0.1. I tried to make those libraries use a previous version of openssl (following this guide). When I tested it on my local machine, vcpkg installs always the latest version (3.0.1). Here an example manifest with boinc:

{
  "name": "boinc",
  "version": "7.18.1",
  "port-version": 4,
  "description": "Open-source software for volunteer computing and grid computing.",
  "homepage": "https://boinc.berkeley.edu/",
  "supports": "!(windows & arm) & !uwp",
  "dependencies": [
    "openssl",
    {
      "name": "vcpkg-cmake",
      "host": true
    },
    {
      "name": "vcpkg-cmake-config",
      "host": true
    }
  ],
  "overrides": [
    {
      "name": "openssl",
      "version": "1.1.1"
    }
  ]
}

I also tried other versions like 1.1.1.m

Any solution?

[BillyONeal]

@JonLiu1993 Some packages that depend on openssl fail to build with version 3.0.1. I tried to make those libraries use a previous version of openssl [...] Any solution?

Version overrides of that form are only applied in an end-user manifest; in a given installed tree only one version of a port may be selected, so for our curated catalog the downstream ports must be fixed.

(This is a C++ rule not a vcpkg rule since different versions of the same thing are generally not link compatible with one another)

[AenBleidd]

I can fix this for boinc since I'm a maintainer of it (we basically have OpenSSL3 support on our master but it's just not ready for release right now) and provide a patch to the port

[Thomas1664]

Version overrides of that form are only applied in an end-user manifest; in a given installed tree only one version of a port may be selected, so for our curated catalog the downstream ports must be fixed.

@BillyONeal If I understand you correctly, we need to wait until all downstream ports are compatible with openssl 3, and there is no way to fix those ports here. I think in this case you can label this PR "depends:upstream-changes". Additionally, can you (or someone else) review this PR, so that merging will be faster if all compatibility issues are fixed?

[BillyONeal]

@BillyONeal If I understand you correctly, we need to wait until all downstream ports are compatible with openssl 3

Yes.

there is no way to fix those ports here.

It is likely reasonable to just patch the downstream dependencies. If they're "rename this thing" kind of complexity we can just do that, if it's more "rewrite this whole component" level changes we probably need to wait for upstreams. It looks like the last major version upgrade for openssl was https://github.com/microsoft/vcpkg/pull/8566/

I think in this case you can label this PR "depends:upstream-changes". Additionally, can you (or someone else) review this PR, so that merging will be faster if all compatibility issues are fixed?

The changes seem OK to me modulo that one nitpick once downstreams are fixed.

[AenBleidd]

Fix for [boinc] port: https://github.com/microsoft/vcpkg/pull/22945

[Thomas1664]

@BillyONeal what about making version 1.1.1 a feature and make the ports that don't support version 3 use that feature?

[dg0yt]

what about making version 1.1.1 a feature and make the ports that don't support version 3 use that feature?

This doesn't work. It breaks versioning in user projects (manifest mode). And it breaks CI where there is only one set of features per package tested.

[luncliff]

Glad there is an in-progress work.

https://github.com/microsoft/vcpkg/pull/22878#issuecomment-1028779172 I had to close #20428 because of libmysql... Honestly, I don't think vcpkg openssl can be updated to 3.0 version unless there are consumer ports that use the removed API.

[Thomas1664]

Glad there is an in-progress work.

#22878 (comment) I had to close #20428 because of libmysql...

@luncliff The problem with libmysql seems to be simple: It uses removed FIPS functions of OpenSSL:

D:\buildtrees\libmysql\src\a9fb86d137-188c26847b.clean\vio\viosslfactories.cc(500): error C3861: 'FIPS_mode': identifier not found
D:\buildtrees\libmysql\src\a9fb86d137-188c26847b.clean\vio\viosslfactories.cc(505): error C3861: 'FIPS_mode_set': identifier not found
D:\buildtrees\libmysql\src\a9fb86d137-188c26847b.clean\vio\viosslfactories.cc(513): error C3861: 'FIPS_mode_set': identifier not found
D:\buildtrees\libmysql\src\a9fb86d137-188c26847b.clean\vio\viosslfactories.cc(527): error C3861: 'FIPS_mode': identifier not found

They need to be replaced with EVP_default_properties_is_fips_enabled and EVP_default_properties_enable_fips.

This could be done via a patch

[Thomas1664]

It turns out that I need to implement openssl-1 in a separate PR.

[Thomas1664]

@JonLiu1993 librabbitmq fails on UWP because deprecation warnings are treated as errors. What is the best way to treat them just as warnings?

[JackBoosY]

@Thomas1664 For uwp, msvc is stricter for code checking. So you have the following three ways:

1. Add /wd${WARNING_NUM} to mask these problems.
2. Make a patch to fix these problems.
3. Add !uwp to the support field in vcpkg.json.

[Thomas1664]

@Thomas1664 For uwp, msvc is stricter for code checking. So you have the following three ways:

1. Add /wd${WARNING_NUM} to mask these problems.

@JackBoosY How to add /wd${WARNING_NUM}? Do I need to do it in a patch or is there a way to do it in portfile.cmake?

[BillyONeal]

@JackBoosY How to add /wd${WARNING_NUM}? Do I need to do it in a patch or is there a way to do it in portfile.cmake?

Unfortunately last I heard OpenSSL had its own custom perl build system thing so you may need to do patching. It's a compiler flag, so if they have a way to pass those in then it would be doable in portfile.cmake.

[Thomas1664]

Unfortunately last I heard OpenSSL had its own custom perl build system thing so you may need to do patching. It's a compiler flag, so if they have a way to pass those in then it would be doable in portfile.cmake.

@BillyONeal My intention was to set the flag in ports that depend on OpenSSL. E.g. in #23241 I tried to set CMAKE_C_FLAGS_DEBUG in the portfile.cmake of libfido2 right after vcpkg_cmake_configure but it didn't work. I had to use a patch. Is this intended/ normal or is there a way of doing this inside portfile.cmake as well?

[BillyONeal]

@BillyONeal My intention was to set the flag in ports that depend on OpenSSL.

Sorry, there's probably a nuance I missed here. Is the issue that the new OpenSSL headers trigger warnings that occur in the builds of other ports rather than OpenSSL itself?

In that case it seems best to try to suppress the warning, if spurious, in the header itself so that it also suppresses it for all customers, including those who aren't other ports.

E.g. in #23241 I tried to set CMAKE_C_FLAGS_DEBUG in the portfile.cmake of libfido2 right after vcpkg_cmake_configure but it didn't work. I had to use a patch. Is this intended/ normal or is there a way of doing this inside portfile.cmake as well?

Right, there is no direct connection between variables in portfile.cmake and variables in the build systems invoked from there unless such connections are made. For example:

https://github.com/microsoft/vcpkg/blob/2b84a6a5889bad2d230acaf41391bc579cd20f81/ports/vcpkg-cmake/vcpkg_cmake_configure.cmake#L304-L333

collects variables which are passed on the command line at:

https://github.com/microsoft/vcpkg/blob/2b84a6a5889bad2d230acaf41391bc579cd20f81/ports/vcpkg-cmake/vcpkg_cmake_configure.cmake#L444-L454

You would need to add extra flags to affect the command line to the call to vcpkg_cmake_configure itself.

[Thomas1664]

Sorry, there's probably a nuance I missed here. Is the issue that the new OpenSSL headers trigger warnings that occur in the builds of other ports rather than OpenSSL itself?

Yes

In that case it seems best to try to suppress the warning, if spurious, in the header itself so that it also suppresses it for all customers, including those who aren't other ports.

I don't know if these warnings are in fact "spurious". The warnings refer to functions that are in fact deprecated and people shouldn't use them. But these functions still work and there is no plan to remove them.

Of course it is less work to disable those warnings inside the header that is responsible for it and it makes sense because consumers of other ports that use OpenSSL can't do anything against those warnings. On the other hand, end users don't realize that they are using deprecated functions.

The alternative is to patch every port that uses OpenSSL to disable deprecation warnings.

What do you consider the better solution?

[BillyONeal]

I don't know if these warnings are in fact "spurious". The warnings refer to functions that are in fact deprecated and people shouldn't use them. But these functions still work and there is no plan to remove them.

Ah, and they are deprecated by OpenSSL?

[Thomas1664]

Ah, and they are deprecated by OpenSSL?

Yes

[BillyONeal]

Ah, in that case I think patching downstream customers as you were doing was right. (Sorry, I'm so used to 4996 being emitted by people calling strcpy I've become blind to "oh yeah, other people can use [[deprecated]])

[Hoikas]

Still waiting for comments on the concern I raised in the issue almost a month ago. It will be unfortunate if vcpkg breaks us and we have to revert to manual dependency management.

[Thomas1664]

Still waiting for comments on the concern I raised in the issue almost a month ago. It will be unfortunate if vcpkg breaks us and we have to revert to manual dependency management.

@Hoikas PR #23223 adds port openssl-1.

[JackBoosY]

Please consider merge #23223 changes into this PR.

[BillyONeal]

The vcpkg maintainers talked about the warning situation today with the following results:

• We would like to know if the warning situation only happens for MSVC because UWP is passing /WX (warnings as errors) or something similar, or if this also affects other compilers like gcc?
• We agree targeted suppression (via pragma warning in headers or /wd4996 in sources) in the downstream ports is the correct behavior.

Still waiting for comments on the concern I raised in the issue almost a month ago. It will be unfortunate if vcpkg breaks us and we have to revert to manual dependency management.

The version mechanism intends to have the capability to support this: we create another branch and add ports we want there, and make them appear in the version database in master without ever introducing the older version itself into master. You'll need a manifest with a version override to get it and we won't be validating all downstreams like we do for the primary catalog but it should enable you to continue.

Alternately you can use or we can create a separate registry for this.

Note: we observe that OpenSSL 1.x goes out of support at the end of 2023 so we encourage you to upgrade.

[Thomas1664]

On OSX no port fails because of deprecation warnings as errors, they all have real errors.

There are some deprecation warnings on Linux as well, but they aren't treated as errors and are not the main cause for a build failure because there are other actual errors. To summarize: the problem on MSVC platforms is much bigger than on Linux although 2 ports treat deprecation warnings as errors on Linux. 1 port has only deprecation warnings.

Exampels: azure-c-shared-utility:

/mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/adapters/x509_openssl.c:140:5: warning: ‘EVP_PKEY_get1_RSA’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
/mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/adapters/x509_openssl.c:150:9: warning: ‘SSL_CTX_use_RSAPrivateKey’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]
[...]

But open62541 treats (deprecation) warnings as errors on all platforms. Additionally, OpenSSL 3 introduces real errors:

/mnt/vcpkg-ci/buildtrees/open62541/x64-linux-dbg/open62541.c:58592:5: error: ‘RSA_size’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
/mnt/vcpkg-ci/buildtrees/open62541/x64-linux-dbg/open62541.c:58663:9: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
[...]

The reason why qpid-proton fails on Linux are exclusively OpenSSL deprecation warnings as errors:

/mnt/vcpkg-ci/buildtrees/qpid-proton/src/a55d0f5f42-727c185a76.clean/c/src/ssl/openssl.c:548:5: error: ‘DH_free’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
[...]

[Thomas1664]

@BillyONeal Is the vcpkg team OK with openssl-1 as an intermediate port for backward compatibility?

[Thomas1664]

libmysql needs to be patched because of conflicts between openssl and openssl-1

[BillyONeal]

@BillyONeal Is the vcpkg team OK with openssl-1 as an intermediate port for backward compatibility?

I don't see why we would need to do that now that we have version override support. The different openssl versions can't be used together so the curated catalog has to pick one.

[Thomas1664]

I don't see why we would need to do that now that we have version override support. The different openssl versions can't be used together so the curated catalog has to pick one.

Does that mean that OpenSSL 3 can't be merged into master until all ports support it?

[BillyONeal]

I don't see why we would need to do that now that we have version override support. The different openssl versions can't be used together so the curated catalog has to pick one.

Does that mean that OpenSSL 3 can't be merged into master until all ports support it?

To a high approximation, yes. If something in the "cone of destruction" is now totally unmaintained we may not hold the update for that but making sure downstreams work is standard operating procedure.

[Thomas1664]

@BillyONeal 2 more questions: How to disable C4996 on Linux as well? This OpenSSL 3 port is missing the file include/openssl/applink.c which is currently needed by at least 1 port. I posted an issue upstream. They suggest to apply this patch on FindOpenSSL.cmake. Is this a possible solution for vcpkg and if so how to apply this patch? As a normal port patch?

[Thomas1664]

To a high approximation, yes. If something in the "cone of destruction" is now totally unmaintained we may not hold the update for that but making sure downstreams work is standard operating procedure.

Looking at the latest CI run in #23223 I have to agree with you. I suspect it is related to azure-c-shared-utility. There might be a few ports that don't introduce conflicts but in the long term if some port introduces a dependence on a port that depends on openssl-1 things will break - not in CI because of CI baseline. On the other hand, it might turn out that bigger or breaking changes need to be made to a port to support OpenSSL 3. In this case there is no other choice than using openssl-1.

[BillyONeal]

How to disable C4996 on Linux as well?

I'm not sure what this means, that's not a thing on Linux. (C4996 is an MSVC++ error code) I know the other compilers have mechanisms to suppress similar warnings but I've not done a lot of that myself recently to be authoritative here. (As in, anything I saw will be worse than "how do I suppress warnings gcc" google queries)

I posted an issue https://github.com/openssl/openssl/issues/17767#issue-1149136981. They suggest to apply this patch on FindOpenSSL.cmake.

IMO we should wait and see what Kitware does with that before proceeding.

Is this a possible solution for vcpkg and if so how to apply this patch?

Not directly. We do have a mechanism to replace builtin find handlers (vcpkg_cmake_wrapper) but that's a sledgehammer solution: we would have to copy the find module out of a cmake, apply the patch, then check the whole thing in, which is really not business we want to be in if we can help it.

On the other hand, it might turn out that bigger or breaking changes need to be made to a port to support OpenSSL 3. In this case there is no other choice than using openssl-1.

openssl-1 is not a choice; it breaks the "all ports must be installable together" rule. (Unless you're saying there are no header/library/symbol names shared between OpenSSL 1 and 3)

That said, I don't believe taking this update is a massively high priority thing. We have time for upstreams to be notified of problems and take action given that OpenSSL 1 doesn't go out of support until the end of 2023.

[Thomas1664]

@JackBoosY @JonLiu1993 @BillyONeal

A quick update: I could fix most ports. Only 3 ports remain broken:

azure-c-shared-utility on x64-linux: Build fails with the following error:

FAILED: CMakeFiles/aziotsharedutil.dir/adapters/x509_openssl.c.o 
/usr/bin/cc -DARCHITECTURE_x86_64=1 -DCURL_STATICLIB -I/mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/inc -I/mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/pal/linux -I/mnt/vcpkg-ci/installed/x64-linux/share/azure_macro_utils_c/include -isystem /mnt/vcpkg-ci/installed/x64-linux/include -D_POSIX_C_SOURCE=200112L -fPIC -Wall -Wextra -Wformat=2 -Wformat-security -DUSE_OPENSSL -Wno-unused-variable -Wno-missing-braces -Wno-missing-field-initializers -Wno-format-nonliteral -g -fPIC -std=gnu99 -MD -MT CMakeFiles/aziotsharedutil.dir/adapters/x509_openssl.c.o -MF CMakeFiles/aziotsharedutil.dir/adapters/x509_openssl.c.o.d -o CMakeFiles/aziotsharedutil.dir/adapters/x509_openssl.c.o -c /mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/adapters/x509_openssl.c
/mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/adapters/x509_openssl.c: In function ‘load_certificate_chain’:
/mnt/vcpkg-ci/buildtrees/azure-c-shared-utility/src/38163cefc7-1f7ff84507.clean/adapters/x509_openssl.c:81:28: error: dereferencing pointer to incomplete type ‘SSL_CTX’ {aka ‘struct ssl_ctx_st’}
   81 |                 if (ssl_ctx->extra_certs != NULL)
      |                            ^~

I can't make it use openssl-1 because of conflicts with openssl.

libmysql Errors will be fixed by updating to the latest version 8.0.28. I already filed PR #23380 but I need help with a patch.

open62541 C2220 + C4090 (warnings about different const qualifiers as error) Can I disable this warning as well?

luasec luasec will be the only port that uses openssl-1. There is no port that depends on luasec. It's impossible to fix until CMake 3.23 is released because the file openssl/include/applink.c is missing. See this issue: https://github.com/openssl/openssl/issues/17767

Edit: luasec works fine with OpenSSL 3. No port will use openssl-1

[Neumann-A]

It's impossible to fix until CMake 3.23

vcpkg-cmake-wrapper.cmake ?

[Thomas1664]

vcpkg-cmake-wrapper.cmake ?

@Neumann-A I added applink to vcpkg-cmake-wrapper.cmake.in. The problem is that applink.c isn't copied properly to packages directory.

[JackBoosY]

Please get failure logs in https://dev.azure.com/vcpkg/public/_build/results?buildId=68371&view=artifacts&pathAsName=false&type=publishedArtifacts

[Thomas1664]

Please get failure logs in https://dev.azure.com/vcpkg/public/_build/results?buildId=68371&view=artifacts&pathAsName=false&type=publishedArtifacts

@JackBoosY Why? I know why those ports are failing and that onnx fails is not my fault, see PR #23411

[JackBoosY]

@Thomas1664 You are right, sorry for the disturb.

[Neumann-A]

The problem is that applink.c isn't copied properly to packages directory.

In the OpenSSL port or where?

azure-c-shared-utility on x64-linux:

either an include is missing or the struct SSL_CTX cannot be accessed directly anymore and a function call to retrieve the extra certs is necessary.

Can I disable this warning as well?

probably. Does the CMakeLists.txt somewhere do /WX or something like that? If yes, just patch it out.

[Thomas1664]

In the OpenSSL port or where?

@Neumann-A It tuned out that the file is copied properly. The only difference between the ports openssl and openssl-1 is that openssl has a DLL called legacy. Looking at the diff, it is obvious that the CMake bug is the problem.