One of the projects I was working in the last period uses CURL that uses OpenSSL version 1.1.1.1 in foreground. At some moment in time, for some technical reasons I was tempted to try using the CPPRESTSDK library. But because I had some local NuGet miss-configuration issues in order to have the CPPRESTSDK library build I realized I need to build it myself. But in order to achieve this, I needed the vcpkg tool.

And, because with a quick search I haven’t found the download and the Azure DevOps of this tool for built was down and no Artifacts available, I said: what if I build it myself?

So, I did it… It lasted some time on my laptop but at the end was fine. I had a brand new vcpkg package and I built the cpprestsdk.

Later, returning to my project and integrating the new cpprestsdk library I realized I was started getting new linking errors.

2>Generating   Code...   
2>libcrypto.lib(comp_lib.obj)   : error LNK2005: COMP_CTX_free already defined in libeay32.lib(LIBEAY32.dll)  
2>libcrypto.lib(comp_lib.obj)   : error LNK2005: COMP_CTX_new already defined in libeay32.lib(LIBEAY32.dll)
2>libcrypto.lib(comp_lib.obj)   : error LNK2005: COMP_compress_block already defined in   libeay32.lib(LIBEAY32.dll)  
2>libcrypto.lib(comp_lib.obj)   : error LNK2005: COMP_expand_block already defined in   libeay32.lib(LIBEAY32.dll)   
2>Creating library C:\dev\ my-project\Build\x64\Debug\myproject.lib and object   C:\dev\my-project\Build\x64\Debug\myproject.exp   
2>C:\dev\my-project\Build\x64\Debug\   myproject.dll : fatal error LNK1169: one or more multiply defined symbols   found

Within the sample solution, the situation is even worth. I was able to find out even more compile errors while the vcpkg is installed.

Vcpkg uses OpenSSL to insure secure connection and googling I found out that starting with the OpenSSL 1.1.x Windows version the static LIB and DLL filenames have changed, so depending on local files, it may affect, the former DLL’s libeay32.dll and ssleay32.dll are no longer available.

I double-checked the environment variables, trying to identify paths containing the old libeay32.dll (that was renamed to openssl.dll) and to remove it. I did such investigation, but I found nothing “suspicions”.
The goal was to avoid the names’ collision in case the linker was looking to link “our” openSSL together with LIBEAY32.dll.

The salvation came from GauthamBanasandra’s suggestion. I just ran the next command within the vcpkg repository local folder.

.\vcpkg.exe integrate remove

After the execution of this command, I was able to build back the project as before. And it was fine for me… I don’t need the vcpkg for other proposes right now.
By the way, this command has to be executed within the vcpkg cloning repository folder. Otherwise, you’ll get an error: Could not detect vcpkg-root in case you don’t have an environment variable VCPKG_ROOT pointing to your vcpkg binary repository.

Off-course, in case you still need vcpkg.exe you can reinstall it temporary with vcpkg.exe integrate install. But then, until there is a fix for this situation or a better workaround, you might face the initial problem I had within OpenSSL based projects. So, most probably you will have to call again vcpkg.exe integrate remove.

The issues are created by the fact the actual vcpkg.exe manager is still using the old openSSL library, libeay32.dll.

Until the Vcpkg team didn’t upgrade to a newer OpenSSL library (1.1.x+), we will have to find such workarounds in order to compile different projects. If someone knows other workaround and is open to share, I would not mind mentioning here her/his idea.

The good news is that an upgrade to the OpenSSL 1.1.x is ongoing. The upgrade issue is already open and the pull request #8566 seems advanced in progress. Let’s stay tuned!