OpenSSL 1.1.1 packaging problem - libcrypto-1_1-x64.dll not found

Development
1

Hi all,

I updated Slicer under a custom app after several months, and the generated installer wouldn’t start up, because libcrypto-1_1-x64.dll was not found.

It seems that in the new version of OpenSSL (1.1.1g) Slicer uses, the DLLs have different names, and maybe there are some differences in packaging that were not addressed? What is strange is that libssl-1_1-x64.dll is in the NSIS directory, but only libcrypto-1_1-x64.dll is not. If I manually copy the DLL from Superbuild\OpenSSL-install\Release\bin into the installed app’s bin directory, then it starts up fine.

I was not able to find where the install step for these DLLs are, and where this should be fixed. Does anyone have an idea? Thanks a lot!

2

Yes, OpenSSL library names have completely changed in the new version. Both libcrypto-1_1-x64.dll and libssl-1_1-x64.dll are correctly installed in latest Slicer Preview Releases.

Have you built your custom application completely from scratch?

3

Yes I believe that I built it clean after changing the Slicer hash and not before. In any case I’ll do another clean build to make sure that this is the case.

4

I packaged the Slicer (currently one commit behind, this hash) that I built (clean) locally with default CMake parameters except for disabled SimpleITK, and I have the same issue there: libssl-1_1-x64.dll is in the NSIS directory, but libcrypto-1_1-x64.dll is not.

5

@Sam_Horvath Do you have similar issues with your custom applications?

6

Please see my last comment. This occurs with my local Slicer build as well, not just the custom app!

I’m not sure if there is a CMake parameter that is set in the factory build but not mine (as I said I use all defaults except that I disable SimpleITK). Or if there is anything specific to my environment that could cause this.

7

In my regular Slicer build, I have both libcrypto-1_1-x64.dll and libssl-1_1-x64.dll in c:\D\S4R\Slicer-build_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-11-win-amd64\bin.

I haven’t disabled SimpleITK, but I would not expect that to make any difference. I’ll start a clean build with the latest master and see if I get the same result.

What Qt version and compiler version do you use? Do you have any third-party antivirus?
Do you have both DLLs listed in c:\D\S4R\Slicer-build_CPack_Packages\win-amd64\NSIS\project.nsi?

8

Thanks a lot @lassoan for checking it!

I use Qt 5.15.0, VS 2019 with its default toolset, and I don’t use third party antivirus.

In project.nsi I only have libssl-1_1-x64.dll. So this is a difference.

9

In case you want to experiment with getting a faster build, the 224 core cloud machine is available with windows for $16 hour :laughing:

1 Like
10

I’ve completed a clean build on my desktop from the latest master version, with Qt-5.15, with v140 toolset (for some reason this was still used in my build batch file), and both libraries were installed.

I’ve started another build using v142 toolset on another computer and will report back when I get the result.

11

Clean build is complete on my other computer, too, and it has libcrypto, too.

I have reference to libcrypto in the following files:

c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\project.nsi 
c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-13-win-amd64\bin\Qt5Network.dll
c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-13-win-amd64\bin\Qt5WebEngineCore.dll
c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-13-win-amd64\lib\Python\Lib\ctypes\util.py
c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-13-win-amd64\lib\Python\Lib\lib-dynload\_hashlib.pyd
c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-13-win-amd64\lib\Python\Lib\lib-dynload\_ssl.pyd
c:\D\S4R\Slicer-build\_CPack_Packages\win-amd64\NSIS\Slicer-4.11.0-2020-08-13-win-amd64\lib\Slicer-4.11\RemoteIO.dll 
c:\D\S4R\Slicer-build\bin\Release\RemoteIO.dll 
c:\D\S4R\Slicer-build\CMake\LastConfigureStep\cmake_install.cmake 
c:\D\S4R\Slicer-build\CMakeCache.txt 
c:\D\S4R\Slicer-build\install_manifest_Runtime.txt 
c:\D\S4R\Slicer-build\SlicerConfig.cmake 
c:\D\S4R\Slicer-build\SlicerTargets.cmake

It seems that RemoteIO, curl, Qt, and/or some Python packages bring in the crypto dll as dependency.

12

Thanks Andras! I did a clean build and packaging on my other computer, and it’s fine there. I’ll try to see the difference between the two environments. Maybe I have an OpenSSL installation by some other program that confuses the package script?