All prerequisites are installed with the following versions: cmake 3.8.2, git 2.14.1 svn 1.9.7 Qt 4.8.7 (including Qt Webkit) gcc 7.1.1
After downloading the 3DSlicer sources (stable 4.6.2) and creating the super build directory, cmake worked without errors using the argument -DCMAKE_BUILD_TYPE:STRING=Debug
When I run make (with multiple jobs) in the super build directory I get various compile errors and the build process fails. Using gcc 5.4 the build process ran longer, but stopped with compilation errors as well.
Am I missing something important here? Or is any gcc version > 4.4 simply not tested/supported. The dashboard seems to use this ancient version of gcc from 2010. Should I maybe use clang instead?
Eight months ago, I could build Slicer on ArchLinux with gcc6 using c++98 throughout.
I tried again a few weeks ago with gcc7. Using c++98, build fails in DCMTK. Using c++11, DCMTK builds, but then it will fail again in BRAINSCommonLib. The latter seems to require c++98 however. I gave up after a few dirty trials.
The problem is not the version of gcc. Resources downloaded automatically require conflicting c++ standards. The bottleneck is BRAINSCommonLib, so it seems to me. I donât know who maintains that library, but it really needs some fresh blood.
Weâll release a new stable version (based on the latest nightly) within a few weeks. So, probably it is not worth spending time with the old stable release, just try to build the latest nightly and let us know if you still have issues.
before configuring with ccmake. The latter allows to switch to advanced options, where the CXXFLAGS declared to ccmake can be checked.
Concerning BRAINSCommonLib, it seems to ignore environment variables totally, and always forces a compilation with c++98. Then VNL, which has been built with c++11 (if not, we wonât get beyond DCMTK), complains that VNL was built with a newer C++ standard. Itâs that last message that hints towards BRAINSCommonLib ignoring environment variables.
I may try a new build this week end (will try to find some time) and post a link to full error output.
Ok, so I tried to built the current nightly (master-branch). I still used gcc 7.1 and tried both C++11 and C++98 (using export CXXFLAGS) with -DCMAKE_BUILD_TYPE:STRING=Release. I always get compile errors in DCMTK about char16_t not being available.
Iâm kind of clueless at the moment. I am always doing clean builds. Should the build process work with gcc and C++11? Or is the current nightly still using C++98?
In file included from /usr/include/unicode/utypes.h:38:0,
from /usr/include/unicode/ucnv_err.h:88,
from /usr/include/unicode/ucnv.h:52,
from [...]/Slicer-SuperBuild-Debug/DCMTK/ofstd/libsrc/ofchrenc.cc:58:
/usr/include/unicode/umachine.h:347:13: error: 'char16_t' does not name a type; did you mean 'wchar_t'?
typedef char16_t UChar;
^~~~~~~~
wchar_t
In file included from /usr/include/unicode/utypes.h:39:0,
from /usr/include/unicode/ucnv_err.h:88,
from /usr/include/unicode/ucnv.h:52,
from [...]/Slicer-SuperBuild-Debug/DCMTK/ofstd/libsrc/ofchrenc.cc:58:
/usr/include/unicode/uversion.h:167:55: error: 'UChar' does not name a type; did you mean 'UChar32'?
u_versionFromUString(UVersionInfo versionArray, const UChar *versionString);
Does this mean that my system header files requires C++11?
Or does this mean that DCMTK requires a C++11 header?
(char16_t is only available since C++11 http://en.cppreference.com/w/cpp/keyword/char16_t)
A verbose make output indicates that DCMTK is compiled with -std=c++98. This seems to be the problem, maybe @chir.set had the same issue?
I think all CXX flags have to be set in CMake (what you set in Slicer are propagated to all libraries). Environment variables should not have any effect.
Probably not. You can look into that header file. It probably has a series of checks to include certain line of code depending on #defined things, and the heuristic doesnât work probably.
I canât debug this, since I donât have a system with a gcc7 compiler. When I tried to debug a similar issue earlier (see notes here: C++11 build errors ¡ Issue #235 ¡ QIICR/dcmqi ¡ GitHub), my experience was that even with CXXFLAGS the options were not propagated properly. There is also a specific comment about a problem in CMake propagating the flags through sub-projects. Can you try to compile just DCMTK, independently from Slicer? Taking one project at a time may be more manageable. Can you also make sure you use the latest CMake?
I also wonder if there is difference between using a compiler that by default uses C++11/14, and a flag needs to be used to override that behavior to use C++98 vs using a C++98 compiler that can be made to use C++11 with extra flags. I think it is the latter that usually is tested/described in the documentation (such as DCMTK instructions for enabling C++11: DCMTK: C++11 support in DCMTK).
Based on the comment from @thewtexhere, CXXFLAGS approach is recommended.
I meant that instead of setting CXXFLAGS directly as an env var, passing CXXFLAGS to CMake should work better, because the setting is cached, consistency can be checked, value can be written to env vars as needed, and it works on all platforms. Note that I have minimal experience with these issues (there are no such problems with Visual Studio), so these are just general comments.
The hints you gave me were very useful, thank you!. I could get the application to build using the following script and gcc 7.1 and cmake 3.9
#!/usr/bin/sh
BUILD=Debug
rm -rf [...]/Slicer-SuperBuild-${BUILD}
mkdir [...]/Slicer-SuperBuild-${BUILD}
cd [...]/Slicer-SuperBuild-${BUILD}
CXXFLAGS="-std=c++98 -Wno-error -fpermissive -DUCHAR_TYPE=uint16_t" CFLAGS="-Wno-error" cmake\
-DCMAKE_BUILD_TYPE:STRING=Release\ # < Bug see revised script below
-DCMAKE_CXX_COMPILER:STRING="g++"\
-DCMAKE_C_COMPILER:STRING="gcc"\
-DSlicer_USE_SYSTEM_QT:BOOL=1\
~/Programme/Slicer
make -j 9
The key changes are the following:
using CXXFLAGS cmake [...] instead of export CXXFLAGS and then running cmake
using -DCMAKE_CXX_FLAGS doesnât work, instead -DCMAKE_CXX_FLAGS_INIT has to be used (seems like an error in the definition of the external project compiler flags)
compiling with -DUCHAR_TYPE=uint16_t
The latter is necessary, because I have ICU v59 (unicode library) installed and it makes use of char16_t per default for defing UChar. By providing a different type this problem can be omitted, hence the preprocessor flag. Versions before ICU v59 didnât use char16_t per default.
Now to the next problem, the application builds, but when I run Slicer the loading screen starts and the application crashes with the following error message:
error: [[...]/Slicer-SuperBuild-Debug/Slicer-build/bin/./SlicerApp-real] exit abnormally - Report the problem.
Thatâs it, no further output . Is there any way to increase the amount of debug output?
The test results may give further information:
I finally got it to build and run. Allthough I had to disable PythonQt with OpenSSL, as I am probably being affected by the same bug that @gcsharp reported. Slicer crashes in the self-compiled OpenSSL library at startup otherwise. Maybe this has something to do with mismatching OpenSSL versions (Qt could be linked against newer versions).
Here is the final working build script that I used:
The initial script didnât use the BUILD variable and always built in Release mode. Unfortunately gcc 7.1 canât be used for building in Debug mode, because LibArchive enforces -Werror (canât be overwritten from global CMake) and it creates warnings during the build. clang 4.0.1 can be used as a replacement.
Summary of the problems that I encountered:
Usage of C++98 has to be enforced with newer gcc verions, as they use C++11/14 as a default
Warning => Error behavior may need to be disabled, if newer compiler versions are used
ICU v59 needs a replacement for the char16_t based UChar definition
LibArchive canât be build in Debug mode using gcc v7.1 (non overridable -Werror and warnings during build), clang 4.0.1 works, Release mode works with both compilers
OpenSSL support has to be disabled for Python Qt (Slicer crashes at startup otherwise)
Finally I can get to develop my own module. Thanks for all the helpful responses, this is a very welcoming community.
It uses Qt5, disables SSL with PythonQt and testing. C++11 is automatically used throughout, and VTK8 gets preferred.
Host tools : gcc 7.1.1, cmake 3.8.2, qt5 5.9.1.
All prerequisites are installed with the following versions: cmake 3.8.2, git 2.14.1 svn 1.9.7 Qt 4.8.7 (including Qt Webkit) gcc 7.1.1
After downloading the 3DSlicer sources (stable 4.6.2) and creating the super build directory, cmake worked without errors using the argument -DCMAKE_BUILD_TYPE:STRING=Debug
When I run make (with multiple jobs) in the super build directory I get various compile errors and the build process fails. Using gcc 5.4 the build process ran longer, but stopped with compilation errors as well.
Am I missing something important here? Or is any gcc version > 4.4 simply not tested/supported. The dashboard seems to use this ancient version of gcc from 2010. Should I maybe use clang instead?
. Is there any way to increase the amount of debug output?