dcmtk's CMAKE and external libs

[pierrechatelier]

[Context]
Compiling DCMTK (3.6.9) under Windows+CMakeGUI+VisualStudio,

I want to use my own builds of external libs (openjpeg, zlib, libtiff) instead of the prebuilt ones that can be downloaded on dcmtk website.

1)some file naming minor problems :
I have observed that trying to use external zlib and libtiff in dcmtk CMake will work, but with some friction about file naming.
It generates VisualStudio projects with a dependency to zlib_d.lib/libtiff_d.lib (Debug configuration) (resp. zlib_o.lib/libtiff_o.lib for Release) , while genuine zlib and tiff builds with CMake will generate zlibd.lib (resp zlib.lib) and tiffd.lib (resp. tiff.lib).
The generated dcmtk visual project can be manually fixed, or the lib files can be copied/renamed so that it finally works, but it is a little inconvenient.

2) WITH_OPENGJPEGINC
Also, when setting WITH_OPENGJPEGINC, dcmtk's CMake creates a secondary WITH_OPENGJPEGINC1 aside the original WITH_OPENGJPEGINC. Why is that ?

3)is it WITH_OPENGJPEGINC honored ?
Finally, when browsing the DLL dependencies of succesfully built dcmtk.dll (for instance with well-known tool Dependency Walker), it does not show any dependance to openjpeg.dll.

[J. Riesmeier]

I have observed that trying to use external zlib and libtiff in dcmtk CMake will work, but with some friction about file naming.
It generates VisualStudio projects with a dependency to zlib_d.lib/libtiff_d.lib (Debug configuration) (resp. zlib_o.lib/libtiff_o.lib for Release) , while genuine zlib and tiff builds with CMake will generate zlibd.lib (resp zlib.lib) and tiffd.lib (resp. tiff.lib).

This file renaming is documented in the INSTALL file (see section "Microsoft Windows with CMake"). The reason for using these "unique" filenames is that it ensures that the external libraries are compiled in the same way as the DCMTK. So, there are less compatibility issues and we have less support requests from Windows users

Re. 2 and 3: OpenJPEG is not used by the public DCMTK, so you can ignore this library. The same is true for libsndfile. Both libraries are used for non-public extensions of the DCMTK and are, therefore, not documented in the INSTALL file.

[pierrechatelier]

This file renaming is documented in the INSTALL file (see section "Microsoft Windows with CMake"). The reason for using these "unique" filenames is that it ensures that the external libraries are compiled in the same way as the DCMTK. So, there are less compatibility issues and we have less support requests from Windows users

Ok, found, but...

Code: Select all

The debug versions of all libraries must be compiled for the multithread debug version of the runtime (/MTd), the release version must be compiled for the non-debug multithread runtime (/MT).  Precompiled versions of all libraries (*) can be downloaded from https://dcmtk.org/develop/#lib-win .

Actually, my zlib and libtiff use /MD[d], as well as the different dcmtk projects in the Visual studio solution. And everything seems to run fine.
So I wonder if I am doing wrong and might encounter run-time hazards ?

(BTW I am using BUILD_SHARED_LIBS)

Code: Select all

    - DCMTK_COMPILE_WIN32_MULTITHREADED_DLL: Controls the Windows build
      model.  When this setting is "ON", DCMTK is compiled with the
      "Multithreaded DLL" build model (/MD or /MDd); when the setting is
      "OFF", DCMTK is compiled with the "Multithreaded" build model
      (/MT or /MTd).  This setting is ignored unless the
      "DCMTK_OVERWRITE_WIN32_COMPILER_FLAGS" option is "ON".  Default: OFF.
    - BUILD_SHARED_LIBS: Build the DCMTK libraries as shared libraries.
      This setting overrides the value of the options
      "DCMTK_OVERWRITE_WIN32_COMPILER_FLAGS" and
      "DCMTK_COMPILE_WIN32_MULTITHREADED_DLL", which are both set to "ON".
      Default: OFF.

[Marco Eichelberg]

When you combine libraries compiled with a different runtime model, the Windows linker will issue a warning about incompatible runtime libraries. If you don't see that, everthing should be fine.

[pierrechatelier]

I assume that since I use BUILD_SHARED_LIBS, dcmtk is using the MD model, hence compatible with MD for zlib and libtiff.
But it means that the doc is incomplete and misleading by mentioning MT as the only possibility for the dependencies.

This is something we can suspect from the variety of builds of the pre-compiled dependencies (https://dicom.offis.de/en/dcmtk/dcmtk-s ... velopment/)

I suggest a doc update

[Marco Eichelberg]

The documentation for BUILD_SHARED_LIBS says that if enabled the setting overrides the value of DCMTK_COMPILE_WIN32_MULTITHREADED_DLL, which is set to ON, i.e. in this case DCMTK is compiled with /MD or /MDd, respectively.
If you have suggestions on how to make the wording easier to understand or clearer, we'd be happy to merge that into the INSTALL files.

[pierrechatelier]

Here is my suggestion :

Code: Select all

-The debug versions of all libraries must be compiled for the multithread debug version of the runtime (/MTd), the release version must be compiled for the non-debug multithread runtime (/MT)

Code: Select all

+The debug and release versions of all libraries must be compiled with the same runtime library dependency as dcmtk (/MT[d] or /MD[d]). Usually, dcmtk is built as /MTd for debug and /MT for release mode, unless it is compiled as DCMTK_COMPILE_WIN32_MULTITHREADED_DLL (which is automatically the case under BUILD_SHARED_LIBS); in this case it's /MDd for debug, /MD for release

[Marco Eichelberg]

Thanks for the suggestion. I have just committed the improved description to our testing branch. This should become visible in the public git in a couple of days.