DICOM @ OFFIS

How is your setup, which version of CMake and DCMTK are you using?

Why did you quote himanshu.mistri's post?

Why do you set LDFLAGS etc. and also use a toolchain file? These settings are performed by / should be performed within the toolchain file.

Which will be better to use ICU or ICONV. Which is supporting more languages? The ICU is in general a bigger library compared to ICONV, with support for many more things e.g. heuristically detecting the encoding of some text. The current DCMTK (3.6.3) however only uses a subset of its possibilities...

I think I can remember some issues with OpenSSL on MacOS that a colleague fixed this year, perhaps after releasing 3.6.3. Can you perhaps try the most recent Git version on DCMTK and see whether that fixes it?

DCMTK overwrites CMAKE_CXX_FLAGS etc. for Visual Studio for various reasons. To switch from /MT to /MD etc. please set BUILD_SHARED_LIBS=ON instead.

Set BUILD_SHARED_LIBS=OFF.

Edit: I solved the problem by changing the CMAKE_INSTALL_PREFIX to another folder in C drive and running VS2017 in admin mode. Yes, these are indeed the "solutions" Google will present you, as always, not really good ones. Changing CMAKE_INSTALL_PREFIX will affect several search paths ins...

Did you choose the correct CMake Generator, i.e. Visual Studio 15 2017 Win64 and not just Visual Studio 15 2017? See https://cmake.org/cmake/help/latest/gen ... 02017.html .

Should be as specified here regarding the Iconv library and whatever is appropriate for the charset library. I'll ask Nikolas to provide some notes about how he tested his commits under MinGW.

MinGW Makefiles will perhaps also work, but we only ever used MSYS Makefiles (I think), so it is untested.

As you see in the commit message of the commit I linked, I added the flag to suppress some warnings and seemingly also tested it with linking the DDLs, but using the .lib files that refer to the DLLs and not the DLLs directly for linking. I can retest that, perhaps it is necessary to detect whether ...

It's live, see commits 0178bca9 and a9561f36.

I see, now that is crazy. It seems to be my fault. Not sure why this leads to a problem for you, but not for us, though.

This is strange. You might try using nmake together with the appropriate vcvars file, since it is the only thing different, but I don't really believe that this would be the issue. I am pretty much out of ideas though.

We have a Visual Studio 2015 x64 build every night, and it does not show this issue. We configure it via: C:/Program Files/CMake/bin/cmake.exe -DCMAKE_BUILD_TYPE:string=RELEASE -DWITH_TESTING:BOOL=ON --no-warn-unused-cli -DBUILD_SHARED_LIBS:BOOL=ON -G "NMake Makefiles" -DDCMTK_WITH_ICONV:B...

No, we only include the iconv library in the libxml2.