CMake Configure OpenSSL Error

(Jean Christophe Fillion Robin) #4

Selecting Visual Studio 15 2017 (with VC++ 2015.3 v14.00(v140) installed) means that Qt compiled for vs2015 should be used.


(Andras Lasso) #5

Also, as described in the build instructions, you may need to use Qt-5.10 or older.

I think the easiest is to specify CMake arguments on the command-line, as shown here:


(James Butler) #6

I think the Windows build instructions should probably be clarified to indicate the VS2015 toolset is required.

Currently it states the following below which seems to suggest building with VS2015(the toolset) is just an option and not a requirement.

For building with VS2015, Qt version 5.10.x or older is required.

Could someone update the wiki with an edit? I think you could just remove the “For building with VS2015” part of that sentence and make it clearer to understand.


(Marc T. McLean) #7

Looking at the command-line code, the documentation states the following assumes the source is in c:\S4

“C:\Program Files\CMake\bin\cmake.exe” -G “Visual Studio 15 2017 Win64” -T “v140” -DQt5_DIR:PATH=C:\Qt\5.10.0\msvc2015_64\lib\cmake\Qt5 C:\D\S4

What is the last argument c:\D\S4? Where is the source c:\S4 specified? Per the cmake documentation, should the last argument be the source?


(Jean Christophe Fillion Robin) #8

the documentation states the following assumes the source is in c:\S4

Thanks pointing this out. I also just updated the wiki page to consistently use C:\D\S4 and C:\D\S4R

The motivation for using short paths is explained in the checkout section, see


(Marc T. McLean) #9

Using cmake from the command prompt or gui and using Qt 5.9.7 msvc2015_64 or Qt 5.12.2 msvc2015_64 and specifying the generator as Visual Studio 15 2017:
if I specify the v140 toolset, I get the error:
CMake Error at CMakeLists.txt:51 (project):
No CMAKE_C_COMPILER could be found.

if I don’t specify the v140 toolset, I get the error:
CMake Error at SuperBuild/External_OpenSSL.cmake:241 (message):
There is no pre-compiled version of OpenSSL 1.0.1h available for
this version of visual studio [1916].

What should I try next?
Is the OpenSSL error related to the v140 toolset?

The reason I want to compile from source is to test 3DSlicer running in a browser like this simple demo I created in C#:


(Jean Christophe Fillion Robin) #10

Could you confirm that the components VC++ 2015.3 v14.00 (v140) toolset for desktop is installed ?

For more details, see


(Jean Christophe Fillion Robin) #11

Yes. We do not have pre-compiled binaries of OpenSSL for this version of Visual Studio.

I want to compile from source is to test 3DSlicer running in a browser like this simple demo I created

Are you planning to build Slicer with webassembly or emscripten ? Or deploy it using amazon appstream ?


(Marc T. McLean) #12

Yes, v140 toolset is installed


(Marc T. McLean) #13

I planned on testing it with Cybele Thinfinity VirtualUI:


(Marc T. McLean) #14

Do you know of anyone using Slicer on Amazon Appstream? I would not need to re-compile but the cost could be higher than using Cybele depending on the amount on time used.

With Cybele you have to re-compile including their libraries, but the cost is $69 USD per concurrent user, one time charge.


(Andras Lasso) #15

You might have multiple Visual Studio versions installed, installed in non-default location, or for some reason the installation may be corrupted.

Try restarting your computer, launch Visual Studio, start CMake from Visual Studio command prompt.

You may also try building a project using the v140 toolset: create a new project in desktop x64 project in Visual Studio, without CMake; right-click on the project (not the solution), choose Properties / General / Platform Toolset: “Visual Studio 2015 (v140)” - you may get a more meaningful error message if something is off.

I had a quick look at Thinfinity VIrtualUI and it does not seem that it could run a Qt-based application. Slicer runs quite nicely in Docker, would that be an option for you?


(Marc T. McLean) #16

Yes, I have both VS2015 and VS2017 installed. Do you know if that is a problem for CMake?


(Marc T. McLean) #17

The end users must be able to access Slicer through a browser. Is that possible using Docker?


(Andras Lasso) #18

This is most likely not a CMake error (the error indicates that CMake fails to build a simple test project with v140 toolset). If you install Visual Studio versions out of order (VS2017 first then VS2015) then it may corrupt the installation and uninstalling both and reinstalling in VS2015, VS2017 order might fix it. Were you be able to build a project with v140 without CMake as I described above?

Yes. Slicer runs in your browser with full GUI.

There is Slicer image with GUI available via web browser but it’s quite old; and there are the regularly updated images but I don’t think any of them is configured to show the GUI in the browser.

@jcfr @pieper Is there a docker image of recent version of Slicer that has web-accessible GUI configured?


(Steve Pieper) #19

Yes, this version has 4.10.1:

docker run -d -p 8080:8080 --name slicer stevepieper/slicer

then open your browser to http://localhost:8080 and click the X11 button (or you can use the direct link).

I’ve been using this approach for a while and I find the performance to be good. I’ve tested it on AWS, Google Cloud and other systems that support docker and it very reliable.

In the README there’s also info on how to use this for batch jobs. I plan to use this quite a bit for some batch analysis jobs, for example using SlicerDMRI.

1 Like

(Andras Lasso) #20

Thanks a lot, this image works very well!

1 Like

(Marc T. McLean) #21

Steve, your container is really good. This could be very useful in environments where IT department’s policies make loading software difficult. This simplifies that significantly.


(Jean Christophe Fillion Robin) #22

That is great, we will look into updating the SlicerDocker project so that up-to-date images are published daily.

Note that images used for Continuous integration are already published there daily.

1 Like

(Steve Pieper) #23

Yes, having a dockerized version of each nighty build work be great for testing, especially for extensions.