Package Details: dcmtk 3.6.0-6

Git Clone URL: https://aur.archlinux.org/dcmtk.git (read-only)
Package Base: dcmtk
Description: a collection of libraries and applications implementing large parts the DICOM standard
Upstream URL: http://dicom.offis.de/dcmtk
Licenses: Other
Submitter: Skatox
Maintainer: Skatox
Last Packager: Skatox
Votes: 33
Popularity: 0.258324
First Submitted: 2008-11-07 13:14
Last Updated: 2015-06-21 22:21

Latest Comments

graysky commented on 2017-02-07 20:02

Doesn't build for me, seems to die here:

/build/dcmtk/src/dcmtk-3.6.0/dcmjpls/libsrc/djerror.h:34:51: fatal error: CharLS/interface.h: No such file or directory

Complete build log here: https://gist.github.com/graysky2/7a23b4cf1c88bfe61be96fd0ec51f678

Others?

nisok commented on 2017-01-06 21:29

Hi to all ...
Just letting you know that the bug persists.

pmattern commented on 2016-12-06 23:09

As of release 3.6.0 CMake is approved on *ix as well, see end of section "BUILDING (Unix)" of file INSTALL you mentioned.
Anyway the problem isn't that DCMTK 3.6.0 doesn't compile when CMake is used but that it doesn't seem to be possible to have it use system CharLS 1.x installed in parallel with 2.x representing the latest stable release. Are you saying it's this particular problem you could solve by using the autotools instead of CMake?

quasarj commented on 2016-12-01 23:21

Why is this being built with CMake at all? The INSTALL file in the distribution says to use autoconf on Unix, and CMake only for Windows.

I get a full compile without errors if I just use autoconf...

pmattern commented on 2016-11-15 19:10

Unfortunately this is a bit beyond my knowledge. What I've already tried is tweaking CMake variables, but to no avail. If you run CMake on the code as patched by this package there are three CMake variables dealing with CharLS. When CharLS is installed in /opt and these variables are set to
> -DDCMTK_WITH_CHARLS=ON \
> -DCHARLS_INCLUDE_DIR:PATH=/opt/charls1/include \
> -DCHARLS_LIBRARY:FILEPATH=/opt/charls1/lib/libCharLS.so[.1.0]
DCMTK compiles flawlessly yet CharLS isn't found due to faulty linking like in
> $ ldd /usr/bin/dcmcjpls
> [...]
> libCharLS.so.1 => not found

Skatox commented on 2016-11-14 03:44

@pmattern thanks for the information. Maybe I could try to patch the source code to find the library somewhere?

pmattern commented on 2016-11-08 00:10

Package charls was updated to the latest stable release 2.0.0 which is no longer compatible with DCMTK 3.6.0 due to massive header changes. I've prepared a package charls1 providing legacy release 1.x which is still maintained upstream and can be used to compile DCMTK 3.6.0 against.
Unfortunately I haven't found a way to make DCMTK 3.6.0 look for system CharLS at locations other than /usr/lib where it particularly looks for libCharLS.so. So I've made package charls1 conflict with all other CharLS versions available in Arch Linux. This seems a bit odd besides package dcmtk is the only reverse dependency of CharLS right now. So if you know a better solution which allows for e. g. installing CharLS 1.x in /opt or so I'm all ears.

Skatox commented on 2016-09-24 13:26

This is the stable version, for snapshot version there's another package.

Skatox commented on 2015-01-15 16:25

@haawda updated it! Also I've updated the PKGBUILD to include fedora's latest patches.

haawda commented on 2014-12-18 21:27

Can you please test for existence of the directory "fedora" before creating it?

[[ -d fedora ]] || mkdir fedora

All comments