iconv(): Does DCMTK really still consider libiconv only?

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
pmattern
Posts: 18
Joined: Tue, 2016-11-08, 13:18

iconv(): Does DCMTK really still consider libiconv only?

#1 Post by pmattern »

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

Code: Select all

checking whether to include libiconv support... no
checking whether the second argument to iconv() is const... no
of the configure script or

Code: Select all

-- Could NOT find LIBICONV (missing:  LIBICONV_LIBRARY) 
-- Could NOT find LIBCHARSET (missing:  LIBCHARSET_LIBRARY LIBCHARSET_INCLUDE_DIR) 
-- Warning: ICONV support will be disabled because libiconv was not found. Correct LIBICONV_LIBDIR and LIBICONV_INCLUDE_DIR and re-enable DCMTK_WITH_ICONV.
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.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: iconv(): Does DCMTK really still consider libiconv only?

#2 Post by Jan Schlamelcher »

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.

pmattern
Posts: 18
Joined: Tue, 2016-11-08, 13:18

Re: iconv(): Does DCMTK really still consider libiconv only?

#3 Post by pmattern »

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

Code: Select all

/usr/local/peter/Tests/DCMTK/Projekt/dcmtk/ofstd/libsrc/ofchrenc.cc:495:28: error: ‘_libiconv_version’ was not declared in this scope
     sprintf(buf, "%i.%i", (_libiconv_version >> 8), (_libiconv_version & 0xff));
                            ^~~~~~~~~~~~~~~~~
[...]
[  5%] Linking C static library ../../lib/libijg16.a
[  5%] Built target ijg16
make: *** [Makefile:139: all] Error 2
EDIT state libiconv release version
Last edited by pmattern on Fri, 2016-11-11, 18:00, edited 2 times in total.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: iconv(): Does DCMTK really still consider libiconv only?

#4 Post by J. Riesmeier »

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?

pmattern
Posts: 18
Joined: Tue, 2016-11-08, 13:18

Re: iconv(): Does DCMTK really still consider libiconv only?

#5 Post by pmattern »

J. Riesmeier wrote: Could you please try to replace "_libiconv_version" with "_LIBICONV_VERSION"?
Err, where? Replacing in ./ofstd/libsrc/ofchrenc.cc, apparently the only appearance of the string within the code of DCMTK, as per

Code: Select all

--- a/dcmtk/ofstd/libsrc/ofchrenc.cc    2016-11-07 12:34:08.791516213 +0100
+++ b/dcmtk/ofstd/libsrc/ofchrenc.cc    2016-11-11 18:18:50.474056246 +0100
@@ -492,7 +492,7 @@
     OFString versionStr = "LIBICONV, Version ";
     char buf[10];
     // extract major and minor version number
-    sprintf(buf, "%i.%i", (_libiconv_version >> 8), (_libiconv_version & 0xff));
+    sprintf(buf, "%i.%i", (_LIBICONV_VERSION >> 8), (_LIBICONV_VERSION & 0xff));
     versionStr.append(buf);
     return versionStr;
 #else
doesn't seem to do the trick.
J. Riesmeier wrote: By the way, what do you mean by "latest libiconv". Is there any newer version than 1.14?
I meant to say latest stable release. Fixed above.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: iconv(): Does DCMTK really still consider libiconv only?

#6 Post by J. Riesmeier »

Replacing in ./ofstd/libsrc/ofchrenc.cc [...] doesn't seem to do the trick.
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.
I meant to say latest stable release
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

pmattern
Posts: 18
Joined: Tue, 2016-11-08, 13:18

Re: iconv(): Does DCMTK really still consider libiconv only?

#7 Post by pmattern »

J. Riesmeier wrote: But isn't it version 1.14?
Sure, as said above meanwhile. Installed by AUR package libiconv, btw.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: iconv(): Does DCMTK really still consider libiconv only?

#8 Post by J. Riesmeier »

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

pmattern
Posts: 18
Joined: Tue, 2016-11-08, 13:18

Re: iconv(): Does DCMTK really still consider libiconv only?

#9 Post by pmattern »

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

Code: Select all

$ ldd /usr/local/lib/libcmr.so.3.6.1 
        linux-vdso.so.1 (0x00007ffe565d2000)
        libdcmsr.so.10 => not found
        libdcmimage.so.10 => not found
        libdcmimgle.so.10 => not found
        libdcmdata.so.10 => not found
        liboflog.so.10 => not found
        libofstd.so.10 => not found
        libiconv.so.2 => not found
        libcharset.so.1 => not found
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3b73f28000)
$ ldd /usr/local/lib/libdcmdata.so.3.6.1 
        linux-vdso.so.1 (0x00007ffdd3852000)
        liboflog.so.10 => not found
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa0c44f8000)
        libofstd.so.10 => not found
        libiconv.so.2 => not found
        libcharset.so.1 => not found
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.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: iconv(): Does DCMTK really still consider libiconv only?

#10 Post by J. Riesmeier »

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
Since you seem to use DCMTK with shared libraries, did you add /usr/local/lib to the environment variable LD_LIBRARY_PATH?

pmattern
Posts: 18
Joined: Tue, 2016-11-08, 13:18

Re: iconv(): Does DCMTK really still consider libiconv only?

#11 Post by pmattern »

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

Code: Select all

$ cat /etc/ld.so.conf.d/libc.conf 
# libc default configuration
/usr/local/lib
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.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: iconv(): Does DCMTK really still consider libiconv only?

#12 Post by Jan Schlamelcher »

pmattern wrote:Maybe Jan Schlamelcher can help track this down if needed as he's got an Arch Linux system at hand, too.
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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest