Agree.

My Mac Slicer build is showing the same error.

Interestingly there are no issues on both the old and new factory. Could you check the CMakeCache.txt to check if the correct DCMTK library are found ? With the new DCMTKConfig.cmake they should.

Do you have any extensions built against a different version of DCMTK that are installed ?

I had completely wiped out my build tree and still had this issue.

DCMTK_DIR:PATH=/Users/200005014/Projects/Slicer4-git/Slicer4-build/DCMTK-build

Here are the paths for me in the shared build (where things work). These paths are correct. I don't have the non-shared build anymore but I believe I checked and the paths were correct.

0000013 Slicer-superbuild $ grep DCMTK_DIR */CMakeCache.txt
CTK-build/CMakeCache.txt:DCMTK_DIR:PATH=/Users/pieper/slicer4/latest/Slicer-superbuild/DCMTK-build
ITKv4-build/CMakeCache.txt:DCMTK_DIR:PATH=/Users/pieper/slicer4/latest/Slicer-superbuild/DCMTK-build
Slicer-build/CMakeCache.txt:DCMTK_DIR:PATH=/Users/pieper/slicer4/latest/Slicer-superbuild/DCMTK-build
Slicer-build/CMakeCache.txt:DCMTK_DIR_ROOT:PATH=/Users/pieper/slicer4/latest/Slicer-superbuild/DCMTK-install

It is strange to see the variable "DCMTK_DIR_ROOT" in your Slicer cache, this probably mean that you didn't do a clean build.

If it exists, make sure to remove the folder "/Users/pieper/slicer4/latest/Slicer-superbuild/DCMTK-install"

Could you then confirm that a clean build or current trunk using default option gives a Slicer executable failing to start ?

Jim already reported that a clean build crashes on startup...

Here are all my DCMTK paths

% grep DCMTK_DIR */CMakeCache.txt
CTK-build/CMakeCache.txt:DCMTK_DIR:PATH=/Users/200005014/Projects/Slicer4-git/Slicer4-build/DCMTK-build
ITKv4-build/CMakeCache.txt:DCMTK_DIR:PATH=/Users/200005014/Projects/Slicer4-git/Slicer4-build/DCMTK-build
Slicer-build/CMakeCache.txt:DCMTK_DIR:PATH=/Users/200005014/Projects/Slicer4-git/Slicer4-build/DCMTK-build

Following the NA-MIC tcon of April 4th, we discussed that Jim will be creating a small program reproducing the issue. Based on his findings, we will be sending an email to DCMTK folks.

DCMTK commit "b2b14d78c" is suspected to introduce the regression:

Update oflog to log4cplus 1.1.0
https://github.com/commontk/DCMTK/commit/b2b14d78cdafcca698b5ef1c0d102386052b9fc3

This is tricky. The following code works without issue.

#include "itkImage.h"
#include "itkImageFileReader.h"
#include "itkImageFileWriter.h"
#include "itkDCMTKImageIOFactory.h"
#include "itkObjectFactoryBase.h"

int main(int argc, char* argv[])
{
itk::ObjectFactoryBase::RegisterFactory( itk::DCMTKImageIOFactory::New(), itk::ObjectFactoryBase::INSERT_AT_FRONT );

typedef itk::Image<unsigned char,2> ImageType;
typedef itk::ImageFileReader<ImageType> ReaderType;

ReaderType::Pointer reader = ReaderType::New();
reader->SetFileName(argv[1]);
reader->Update();
reader->GetImageIO()->Print(std::cout);

typedef itk::ImageFileWriter<ImageType> WriterType;

WriterType::Pointer writer = WriterType::New();
writer->SetInput(reader->GetOutput());
writer->SetFileName(argv[2]);
writer->Write();
}

I guess I need to get the "default" factories not to load and have the DCMTKImageIO library loaded from the ITK_AUTOLOAD_PATH

I modified my ITK build so that GDCM is not in the default factory list.

Then I modified the DCMTKImageIOFactory to have an itkLoad function.

The following test program then runs without issue. It loads DCMTKImageIO from the ITK_AUTOLOAD_PATH.

#include "itkImage.h"
#include "itkImageFileReader.h"
#include "itkImageFileWriter.h"
#include "itkExceptionObject.h"

int main(int argc, char* argv[])
{
typedef itk::Image<unsigned char,2> ImageType;
typedef itk::ImageFileReader<ImageType> ReaderType;

ReaderType::Pointer reader = ReaderType::New();
reader->SetFileName(argv[1]);
try
{
reader->Update();
}
catch (itk::ExceptionObject &exc)
{
std::cerr << exc;
}
reader->GetImageIO()->Print(std::cout);

typedef itk::ImageFileWriter<ImageType> WriterType;

WriterType::Pointer writer = WriterType::New();
writer->SetInput(reader->GetOutput());
writer->SetFileName(argv[2]);
writer->Write();
}

A program using just the DCMTK logger works if only linked against oflog

#include "dcmtk/oflog/oflog.h"

int main(int argc, char* argv[])
{
OFLogger my_log = OFLog::getLogger("dcmtk.apps.sample");

OFLOG_INFO(my_log, "Testing the DCMTK logger");
}

But when linked against oflog and ITK_LIBRARIES, then it crashes

That is great. Seems you are able to come with a simpler use case :) Do you think, you could come with an example that produce the crash without involving ITK at all ?

By for example, having:

• one shared library statically linking against oflog (similar to the ITKDCMTKIO library)
• a main executable linking statically against oflog and dynamically against the shared library.

With that in hand, we would be able to have the argument to discuss with Offis team.

Thanks again,
Jc

Where do we stand on this? Right now people need to change DCMTK to shared in order to run their builds at all on mac (maybe linux too). I think we should move to a shared DCMTK to fix the problem rather than trying to convince the Offis people to accept our use case (which they think is not really a valid one if I understand correctly).

I tried writing a test program that used oflog like above AND did a dlopen on a library that used oflog. I thought this would mimic the ITK issue.

Unfortunately, that program works find.

I had to change my Mac built to using a shared DCMTK as I had other work that needed my attention.

I did a completely fresh test build in release mode with DCMTK built shared:

Here is the resulting package, which works for me and is able to load dicom data:

https://s3.amazonaws.com/extra.isomics.com/tmp/Slicer-4.2.0-2013-04-24-macosx-amd64.dmg

All the shared libraries appear to be in the normal spots, so I would think this will work on all platforms.

@jcfr - do you have an objection to having this change checked in? It only seems for the better from my point of view.

@steve: The only think I am thinking about are dcmtk apps. I think they won't work without being run using the Slicer launcher. If this is a none issue. It should be good.

On platform like windows and linux, the launcher setting would have to be updated. There are no rpath within the install tree.

No real show stopper.

The dcmtk apps (dcmdump, storescp) are used now in subshells from slicer (AFIAIK) so they should inherit the environment and work I would think. If people need to use slicer's compiled versions of them outside slicer, then I guess having to use the launcher is fair, just like running a CLI.

Regarding the launcher though, I don't think a change needs to be made since the dcmtk libraries should show up in lib/Slicer-4.2 along with all the other shared libraries.

Since this is a problem for developers right now, I'm going to check in the change and we can see if there is any fallout.

Fixed in this commit:

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21914

Confirmed that dcmtk built in shared mode works correctly on nightly builds for all platforms.

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21942
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21944
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21947
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21949