DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Fri, 2018-04-20, 11:23

All times are UTC + 1 hour




Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Fri, 2016-11-11, 14:04 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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:
checking whether to include libiconv support... no
checking whether the second argument to iconv() is const... no
of the configure script or
Code:
-- 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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 15:56 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 231
Location: Oldenburg, Germany
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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 17:48 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
As I just saw compiling against libiconv 1.14 seems to fail in addition:
Code:
/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.

Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 17:54 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1928
Location: Oldenburg, Germany
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?


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 18:40 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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:
--- 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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 18:46 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1928
Location: Oldenburg, Germany
Quote:
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.

Quote:
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


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 18:56 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
J. Riesmeier wrote:
But isn't it version 1.14?
Sure, as said above meanwhile. Installed by AUR package libiconv, btw.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 18:58 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1928
Location: Oldenburg, Germany
I'm sorry, then I'm lost... I downloaded the official source code package (see above), compiled and installed it.


Top
 Profile  
 
PostPosted: Wed, 2016-11-23, 13:20 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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:
$ 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.


Top
 Profile  
 
PostPosted: Wed, 2016-11-23, 13:28 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1928
Location: Oldenburg, Germany
Quote:
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?


Top
 Profile  
 
PostPosted: Fri, 2016-11-25, 19:18 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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:
$ 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.


Top
 Profile  
 
PostPosted: Mon, 2016-11-28, 10:48 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 231
Location: Oldenburg, Germany
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group