From Macro Nolden - https://github.com/commontk/CTK/issues/178:

The latest DCMTK snapshot includes support for libiconv. This is automatically detected by DCMTK, but the CTK Superbuild does not link libiconv to all DCMTK-dependent targets. This results in errors like this:

Undefined symbols for architecture x86_64:

"_libiconv_close", referenced from:
OFCharacterEncoding::closeDescriptor(void&) in libofstd.a(ofchrenc.cc.o)
"_libiconv_open", referenced from:
OFCharacterEncoding::openDescriptor(void&, OFString const&, OFString const&) in libofstd.a(ofchrenc.cc.o)
"_libiconvctl", referenced from:
OFCharacterEncoding::convertString(void, char const, unsigned long, OFString&, bool) in libofstd.a(ofchrenc.cc.o)
"_libiconv", referenced from:
OFCharacterEncoding::convertString(void, char const, unsigned long, OFString&, bool) in libofstd.a(ofchrenc.cc.o)
ld: symbol(s) not found for architecture x86_64

After a short discussion with the DCMTK team I think the best solution is to deactivate libiconv support for now since it's not easily detectable whether it is turned on or off. Encoding support is still supported by our ctkDICOMDataset wrapper class.

OFFIS DICOM Team dicom@offis.de

May 15 (3 days ago)

to Andras, pieper
Michael wrote:

Today, we published a new snapshot of DCMTK, by the way:

... and we've also "published" a new snapshot of DCMRT:

http://nero.offis.de/download/dcmrt_20120515.tar.gz

See dcmtk/CHANGES.361 and dcmtk/dcmrt/CHANGES files for details on what has changed since the last snapshot in February. Btw, the DCMRT library has its own COPYRIGHT file, which is stored in the "dcmrt" subdirectory. Anyway, it's licensed under the BSD license (in the same way as the DCMTK is).

Regards,
Jörg Riesmeier

Would it be possible to try to build against this recent snapshot ?

As discussed at project week, the plan is to make DCMTK a toplevel dependency of slicer's superbuild and pass this down to CTK and to ITKv4.

Here is a topic branch that implements this:

https://github.com/pieper/Slicer/tree/externalDCMTK

https://github.com/pieper/Slicer/commit/716dc9496642b6b08e9308227111707d6a2e6901

I've tested the build (not install) on mac and windows and it works as expected.

Right now it uses the master of dcmtk.git.rt, but we'll want to standardize on a snapshot before we merge this to slicer.

From Jc - June 28 2012:

Hi Steve,

As soon as the following items are resolved, I guess it should be good to go:
1) standardize on a snapshot
2) see commitcomment-1517211 - Use SlicerMacroEmptyExternalProject
3) see commitcomment-1517974 - Update commit message
4) see commitcomment-1517984 - Honnor option Slicer_BUILD_DICOM_SUPPORT -
5) see commitcomment-1517998 - Use slicer_config_set_ep in SlicerConfig.cmake
6) see commitcomment-1518011 - Set variable Slicer_EXTERNAL_PROJECTS_CONFIG
7) see commitcomment-1518019 - Update UseSlicer.cmake.in

From Kent - June 29 2012:

My ITK patch to add DCMTK Image I/O has a provision for USE_SYSTEM_DCMTK, that I've tested. When that gets further along I will test it in slicer.

Steve,

Could you consider the comments I reported and integrate into Slicer, then when we will need to test against ITKv4 it will a trivial update of External_ITKv4.cmake.

Thanks
Jc

From Jc - July 19 2012:

Hi Kent,

Do you know when your topic related to ITKv4 and DCMTK will be integrated to ITK master ?

Slicer will pass the appropriate variable to ITKv4 when this one will supported DCMTK. See [1] and [2]

Thanks
Jc

[1] https://github.com/Slicer/Slicer/commit/b26b6c1dd8d910e96a8e58eb0d1e37a6a3ac2e8b
[2] https://github.com/Slicer/Slicer/commit/

From Kent - July 19 2012:

I'm hoping to do it soon, but I have some issues to resolve, mostly with
CMake issues, and then if I can get it merged, I'm hoping to get more
testing on it. One big test, which is rather important to anyone working
with DWI/DTI images, is that currently ITK can't open single-file DWI
images.

Fixed in r20654