CTKDICOMCore linker error

[saschazelzer]

On my Ubuntu 11.04 machine, libCTKDICOMCore does not link due to missing zlib symbols.

Adding "z" to the link libraries of CTKDCIOMCore would solve this issue. Is this the way to go?

[trabs]

Hi,

as a quick fix: yes.

Under Unix-like systems DCMTK detects which third party libraries are available during compilation, namely LIB...ZLIB, PNG, TIFF, XML and OPENSSL. If those libs are detected and used (linked) into the object files in DCMTK, then they must also be linked in CTK.

The best way would be to "export" the libraries found during DCMTK build to CTK build where appropriate. I am not sure what is the right way to do this in CMake.

If the feature connected to those 3rd party libs (DCMTK runs fine without them) are not needed anyway, one could specify this in DCMTK.cmake as -DDCMTK_WITH_TIFF:BOOL=OFF. These are the features you loose (from what I remember by heart):

OpenSSL: DICOM signatures and TLS-secured communication (rarely used both in DICOM)
ZLIB: Deflated Transfersyntax (mainly useful if transferring non-image objects that should be compressed)
PNG, TIFF: Used as output formats in dcm2pnm and the corresponding library dcmimage/le in order to convert DICOM images to PNG or TIFF.
XML: convert XML (DCMTK's own format/DTD) to DICOM (used by xml2dcm, but not for dcm2xml).

I would say it would make most sense to disable the third party libraries for now if it is not very simple to add to the CTK linker flags.

[saschazelzer]

Okay, manually setting DCMTK_WITH_ZLIB to OFF works, CTKDICOMCore does
not seem to use any zlib related features.

From what I know from other toolkits, you (DCMTK) would either support
components in the FindDCMTK.cmake script (which is called during
find_package(DCMTK ...) ) or provide a CMake variable like
DCMTK_USE_FILE which points to a CMake file which configures CMake
variables like DCMTK_LIBRARIES according to specified requirements. For
example in CTK we would do:

set(DCMTK_USE_ZLIB 1) # or 0
include(${DCMTK_USE_FILE}) # set up DCMTK_LIBRARIES etc. correctly (i.e.
containing "z")
target_link_libraries(mylib ... ${DCMTK_LIBRARIES})

For a "quick fix", I would agree to set DCMTK_WITH_ZLIB to off, since we
do not use it in CTK yet.

On 08/02/2011 01:54 PM, trabs wrote:

Hi,

as a quick fix: yes.

Under Unix-like systems DCMTK detects which third party libraries are available during compilation, namely LIB...ZLIB, PNG, TIFF, XML and OPENSSL. If those libs are detected and used (linked) into the object files in DCMTK, then they must also be linked in CTK.

The best way would be to "export" the libraries found during DCMTK build to CTK build where appropriate. I am not sure what is the right way to do this in CMake.

If the feature connected to those 3rd party libs (DCMTK runs fine without them) are not needed anyway, one could specify this in DCMTK.cmake as -DDCMTK_WITH_TIFF:BOOL=OFF. These are the features you loose (from what I remember by heart):

OpenSSL: DICOM signatures and TLS-secured communication (rarely used both in DICOM)
ZLIB: Deflated Transfersyntax (mainly useful if transferring non-image objects that should be compressed)
PNG, TIFF: Used as output formats in dcm2pnm and the corresponding library dcmimage/le in order to convert DICOM images to PNG or TIFF.
XML: convert XML (DCMTK's own format/DTD) to DICOM (used by xml2dcm, but not for dcm2xml).

I would say it would make most sense to disable the third party libraries for now if it is not very simple to add to the CTK linker flags.

[finetjul]

+1 for DCMTK_USE_FILE, until that happens, let's turn off DCMTK_WITH_ZLIB.

[trabs]

Alright ;) I will take care of it tomorrow and disable all 3rd party libs as a quick fix. Next days I will look for a better solution.

[saschazelzer]

Ahm, okay. I just disabled zlib, all other defaults work out of the box on Ubuntu 11.04 for now.

[trabs]

The thing is that others might encounter the same problems with the other libs, so it is more safe to disable them all per default.

[saschazelzer]

Okay, you are right. Looking at the CMakeLists.txt file of DCMTK, the
only options which are ON by default and which could lead to potential
problems are

DCMTK_WITH_TIFF
DCMTK_WITH_PNG
DCMTK_WITH_ZLIB

Correct?

I also think a first simple version of a DCMTKConfig.cmake file
providing DCMTK_INCLUDE_DIRS and DCMTK_LIBRARIES variables would not
take very long to write and would help a lot.

Thanks,
Sascha

On 08/02/2011 10:50 PM, trabs wrote:

The thing is that others might encounter the same problems with the other libs, so it is more safe to disable them all per default.

[trabs]

Hi, I disabled all 3rd party libs for now.

Your list above is correct, however, I also disabled OpenSSL since it costs a line and nobody has to do research why OpenSSL is not explicitly turned off.

I will look into a DCMTKConfig.cmake next days. Also the FindDCMTK script is not optimal, however, I am not sure about the best way to deal with different DCMTK versions, i.e. there are older versions with less libraries inside DCMTK (like oflog, dcmjpls).

Thanks for reporting and solving issue :)

[saschazelzer]

Great, thanks!

On 08/03/2011 10:35 AM, trabs wrote:

Hi, I disabled all 3rd party libs for now.

Your list above is correct, however, I also disabled OpenSSL since it costs a line and nobody has to do research why OpenSSL is not explicitly turned off.

I will look into a DCMTKConfig.cmake next days. Also the FindDCMTK script is not optimal, however, I am not sure about the best way to deal with different DCMTK versions, i.e. there are older versions with less libraries inside DCMTK (like oflog, dcmjpls).

Thanks for reporting and solving issue :)

[nocnokneo]

Are there any updates on this issue? Is it still dependent on DCMTKConfig.cmake?

[fedorov]

Guys, by disabling zlib you lose support of the deflated transfer syntax. No better solution, huh?

[pieper]

At the CTK level it's probably easiest to leave all of these off. But it's also possible for applications that use CTK to point to their own DCMTK build that can have these turned on (for example, Slicer builds both dcmtk and zlib so it could put them together before passing down to CTK).

[jcfr]

Since we can act upon all the pieces, zlib, dcmtk ... supporting this should be possible.