Describe the bug
Not sure if this is known, but updating openssl breaks it. It appears to be looking for some files related to libressl, which it erroneously thinks has been installed, and fails to update. This cascades, breaking all dependent libraries (eg: boost-asio). So basically everything breaks.
Environment
Windows 10, VS2019 latest (as of today)
To Reproduce
Expected behavior
Failure logs
I don't have the logs on this system; logs are on work system. Error is from line 2 of the port file, which is looking for ssl.h, which is generated in previous versions of openssl itself. Cleaning out installation headers still breaks on install, though, so should be trivial to reproduce.
I didn't see an existing issue for this, but it's hard to believe it's not known, so feel free to close this issue out if it's a duplicate.
Are we STILL having issues building OpenSSL?
It looks like most of the issues reported here are recurrent!

@nick42 Can you post here some screenshots showing the error messages?
In my case the dependent library was pybind11, trying to pull openssl, but conflicting with already existing files in <vcpkg root>/installed/x64-windows/include/openssl (even though neither openssl or any other *ssl flavor was installed).
then vcpkg thought this was a conflict with libressl/boringssl and everything failed.
The only way to "fix" this was to completely remove vcpkg and then reinstall everything.
It's very disappointing that one git pull can lead to lots of wasted time due to issues like this.
@nick42 Have you had issues before with OpenSSL? Like in Feb this year?
Is this a recurrent issue?
@foolnotion What is the relationship between libressl/boringssl and OpenSSL?
@sfhacker I think they are just mutually exclusive due to conflicting implementations. otherwise I have no idea.
see here: https://github.com/microsoft/vcpkg/blob/63dccf771d0bf84f8a1e111c8b53a4057d4c0a18/ports/openssl/portfile.cmake#L1
my guess is that a previous version of vcpkg populated ${CURRENT_INSTALLED_DIR}/include/openssl/ssl.h (even though there was no openssl/libressl/boringssl package installed) and then ended up with this conflict/block after upgrading vcpkg.
This is due to the recent change in the openssl port, which unifies the 3 different ports (windows, uwp and unix) into one. As a result, please remove any old openssl ports you have installed before.
@longnguyen2004 although the openssl files were present, vcpkg did not see the openssl port as being installed, and therefore could not be removed. this is why in my case only manually deleting the folder solved the issue. perhaps the upgrade caused openssl (which was probably installed indirectly as a dependency) to not be detected as installed anymore. therefore it couldn't be fixed simply by vcpkg remove openssl.
Back then, removing openssl doesn't actually remove openssl, you have to remove openssl-windows (or uwp, unix) for it to actually be removed.
@Neumann-A Maybe add a warning into the portfile? This could confuse people
The error message I was getting is the same as was posted in 14451, for reference.
I have no old ports or alternative implementations installed for openssl (that I am aware of); I just did an "upgrade", and encountered the error. I do have boost installed, though, so I have its dependencies.
@sfhacker I did not have previous issues, but at work we do not pull third-party dependencies too regularly. That's one of the things which moving to vcpkg was supposed to improve, but catastrophic failures like this make us question that effort.
@foolnotion I actually manually deleted the "includes" directory to see if that helped, and it did not. Just building the combination of packages I have with the current broken port of openssl was sufficient to cause it to fail to build.
I can see about posting the log, but I do not know how to add that anonymously, and I do not put any personal credentials on company systems (for numerous reasons), so that might be tricky. If there's a way to attach files via email or something, I can certainly do that.
vcpkg upgrade is just a dangerous command and it is really hard to correctly remove/deprecate a port due to it.
Especially as pointed out:
This cascades, breaking all dependent libraries (eg: boost-asio). So basically everything breaks.
In general I would advise to not use vcpkg upgrade and rather use the binary caching feature with vcpkg install in another folder.
The solution to this issue is to simply use vcpkg remove openssl-windows:<yourtriplet> (or openssl-uwp or openssl-linux but that depends on your triplet)
Okay, I'll give that I try on Monday.
If that does in fact resolve the issue, allow me to make two follow-up suggestions:
vcpkg upgrade is inherently bad/dangerous, then it should emphatically not be the recommended method for upgrading versions of libraries, as it currently is. Alternatively, perhaps it could be updated in some manner to not break with these sorts of changes. In either case, it would also be great if the CI/test pipeline detected breaking cases like this (ie: where vcpkg upgrade would be catastrophic), and at least warn users about it.Back then, removing openssl doesn't actually remove openssl, you have to remove openssl-windows (or uwp, unix) for it to actually be removed.
@Neumann-A Maybe add a warning into the portfile? This could confuse people
@nick42 @longnguyen2004 @foolnotion cc: @Neumann-A
vcpkg upgrade for a custom script to do a vcpkg remove [ports] --recurse followed by a vcpkg install [ports] --editable --x-use-aria2 --keep-going.
Most helpful comment
14457 is supposed to fix this, just have to wait for it to merge