DICOM @ OFFIS

Regarding iconv() it seems DCMTK can only make use of libiconv and disables the feature when this particular library is missing as any attempt to make it use e. g. the implementation in glibc fails ending in messages like
of the configure script or
of CMake.

If so this behaviour should definitely be changed as relying on glibc is by far the more common thing to do. Library libiconv is available in the AUR of Arch Linux only and seems to be missing completely in Debian, Fedora and openSUSE.

On a side note there's a minor inconsistency regarding the CMake variables.
Both 'cmake -LAH' and cmake-gui are stating DCMTK_WITH_ICONV, LIBICONV_INCLUDE_DIR and LIBICONV_LIBRARY, the output of simply running cmake as posted above does mention the former two as well but states LIBICONV_LIBDIR instead of the latter.

Yes, this sucks! It is already in our bug tracker as a private issue (I think because it is in German). It's not so easy to fix though, somebody already made a patch trying to use the functions from glibc but it turns out DCMTK also uses functions like locale_charset() that are only in the real iconv library and not inside glibc.

As I just saw compiling against libiconv 1.14 seems to fail in addition:


EDIT state libiconv release version

Could you please try to replace "_libiconv_version" with "_LIBICONV_VERSION"?

By the way, what do you mean by "latest libiconv". Is there any newer version than 1.14?

Err, where? Replacing in ./ofstd/libsrc/ofchrenc.cc, apparently the only appearance of the string within the code of DCMTK, as per
doesn't seem to do the trick.

I meant to say latest stable release. Fixed above.

Yes, sorry, I meant this file. I thought it was obvious since your compiler stumbled over it.

_LIBICONV_VERSION is a macro that is also used at other places in "ofstd/libsrc/ofchrenc.cc", i.e. the compiler should already fail before line 495.


But isn't it version 1.14? This is exactly the version I use: http://ftp.gnu.org/pub/gnu/libiconv/lib ... .14.tar.gz

Sure, as said above meanwhile. Installed by AUR package libiconv, btw.

I'm sorry, then I'm lost... I downloaded the official source code package (see above), compiled and installed it.

The failure to build against libiconv seems to correspond with the build environment.
DCMTK 0bf28e1 compiles flawlessly against manually installed libiconv 1.14 on up-to-date Debian stretch (testing) here as well while on Arch Linux there's still the failure as depicted above (exept the error messages state capitalized _LIBICONV_VERSION instead of _libiconv_version).
Maybe Jan Schlamelcher can help track this down if needed as he's got an Arch Linux system at hand, too.

Btw. on Debian the linking may go pretty wrong depending on the locations where DCMTK and its dependencies are installed.
E. g. when both DCMTK and libiconv are installed to /usr/local lots of libraries aren't found like in
At a glance problems like this cannot be seen when DCMTK and libiconv are both installed to /usr (-DCMAKE_INSTALL_PREFIX=/usr and --prefix=/usr respectively), didn't test other combinations in terms of /usr vs. /usr/local.

Since you seem to use DCMTK with shared libraries, did you add /usr/local/lib to the environment variable LD_LIBRARY_PATH?

Is LD_LIBRARY_PATH still commonly used these days in the first place? I've never seen it being set on any recent Linux distribution according to env and was hence assuming that the paths are detected by other means like /etc/ld.so.cache or CMake itself.
That aside I had been expected /usr/local/lib to be handled correctly due to
and as I had expected the linker to be set up properly when neither cmake nor the various make invocations throw any warning.
More importantly, that path thing was rather intended as a hint as I stumbled upon it. It does not represent an issue for me as I never install libraries to /usr/local so please understand that I'm not too motivated to spend time on that matter.

I did not actually test it so far, but I remember the partial iconv implementation inside the stdlibc also provides <iconv.h>, but this header does not define _LIBICONV_VERSION. So most likely the wrong header file takes precedence and the defines therefore don't exist.