Why does Slicer need its own OpenSSL?

I’m looking into fixing this irritating bug:
https://issues.slicer.org/view.php?id=4125

But first I have a question. Why does Slicer need its own OpenSSL? Could it work using the one my OS provides?

This was motivated to have a consistent environment on Linux, macOS and Windows.

Since different Os ship if different version, it would be hard to ensure the distributed binaries works everywhere.

We are also overdue for an OpenSSL update.

When I have some cycle, I will setup a VM to debut this

Thank you Jc.

Just to clarify, this is not about distributed binaries. Those are fine.

I will try the OpenSSL update and report back.

Great. In that case, I suggest you focus on Qt5 + VTK8. OpenSSL requirements for Qt 4.8 are different from the one of Qt5.

Confirm that Super-build upgrade to OpenSSL 1.0.2l resolves issue with
Debian stable. Slicer launches without crashing. This test was
performed with VTK 8 and Qt 5.7.1.

Older linux install may supply Qt linked against 1.0.1. Possibly
these will crash.

Would the next step be the below to generate windows?

The good news is that the script has been updated (see here and PR jcfr/qt-easy-build#28).

We need to consolidate the windows OpenSSL build scripts and generate windows openssl archives

Wow, outstanding! Is there anything I can do to help?

I tried to upload the new OpenSSL to midas, so I can create a pull
request. I don’t have permission to push to the OpenSSL community.
Would a download from the midas personal folder be acceptable?

Thanks Greg

Are you talking about generating OpenSSL build for windows ?

Which version of script did you use (a link to it would be great). I would then make sure the jcfr/qt-easy-build is up-to-date first.

First I was going to address linux by uploading the tarball. That is the highest priority because of the build failure.

But yes, I did plan to proceed with windows after that.

All set. See https://packages.kitware.com/item/10336

Soon we will transition away from packages.kitware.com and host the OpenSSL build artifacts in a project like GitHub - Slicer/Slicer-OpenSSL: OpenSSL sources and builds used in Slicer-based projects.

Please note thta Arch Linux ships with openssl 1.1.0.g. Version 1.0.2.l is optional. If Slicer does not ship its own OpenSSL libs, it won’t run on all distros.

If Arch ships 1.1.0g, presumably it links Qt against 1.1.0g as well.

Are you saying this version not supported by PythonQt or curl or some other Slicer-provided dependency?

You’re the best Jc. Pull request submitted.

@gcsharp OpenSSL version used on Unix has been updated to 1.0.2n. See r26841

As a side note, your authorship will be restored when we transition to GitHub. See https://www.slicer.org/wiki/Documentation/Labs/TransitionToGit#Authorship

To follow up on this, pre-built archive of OpenSSL 1.0.2n for VS2013 and VS2015 are now available. See https://github.com/Slicer/Slicer-OpenSSL

@jcfr can you confirm - is Slicer supposed to build in Debug mode with binary-installed Qt5 on Mac with OpenSSL enabled

or

we need to compile Qt5 from source with SSL enabled to be able to enable SSL in Slicer?

I ran into a problem compiling Slicer on Mac, which seem to have disappeared after disabling SSL, but I could not find the answer in https://www.slicer.org/wiki/Documentation/Nightly/Developers/Build_Instruction on whether I am supposed to do this or not.

FWIW, this is my primary build configuration, so I can confirm Debug build with PythonQt+SSL enabled works (aside from stepping in to upstream Qt library code, as expected). I’m using Qt 5.9.3 from the online installer, on macOS 10.12.

1 Like

Thanks @ihnorton! I think that issue was related to command line tools being uninstalled/inaccessible as a result of Xcode update. I discovered this while looking for a solution to PCRE build issue. After installing the command line tools and restarting, I no longer had SSL problem.

Just one thing I didn’t understand: what did you mean by “aside from stepping in to upstream Qt library code, as expected”?

I mean in the debugger: if you put a breakpoint in Slicer-build libraries then you can single-step through the file because they are built in debug mode. But you won’t be able to set a breakpoint in to a Qt library (QtCore.dylib etc.), and if you step in to one from Slicer you will just see assembly – because the Qt library is built in release mode, and doesn’t include mach-o symbols with location information for the debugger.

1 Like