Package Details: dcmtk 3.6.0-6

Git Clone URL: (read-only)
Package Base: dcmtk
Description: a collection of libraries and applications implementing large parts the DICOM standard
Upstream URL:
Licenses: Other
Submitter: Skatox
Maintainer: Skatox
Last Packager: Skatox
Votes: 32
Popularity: 0.054599
First Submitted: 2008-11-07 13:14
Last Updated: 2015-06-21 22:21

Latest Comments

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
> -DCHARLS_INCLUDE_DIR:PATH=/opt/charls1/include \
> -DCHARLS_LIBRARY:FILEPATH=/opt/charls1/lib/[.1.0]
DCMTK compiles flawlessly yet CharLS isn't found due to faulty linking like in
> $ ldd /usr/bin/dcmcjpls
> [...]
> => 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 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

Skatox commented on 2014-01-23 23:22

I've updated to include a temporary solution.

CodingNickNick commented on 2014-01-23 16:07

Removing -Wl,O1 from the LDFLAGS fixed the issue here. Not sure why this is, I know little of the specifics of the linker. However, with "options=('!buildflags') this makes DCMTK build again. Could you do that?

nylocx commented on 2014-01-21 09:48

I just build dcmtk with current libpng and all fedora patches manually on my system. So it's not a libpng problem, it's somehow a problem with your PKGBUILD file. Im new to this but I will list my steps to manually compile dcmtk and maybe you can figure out what is different.

cd builds
tar -xvzf dcmtk-3.6.0.tar.gz
mkdir rpm
cd rpm ../dcmtk-3.6.0-16.fc20.src.rpm
cd ../dcmtk-3.6.0
rm -rf dcmjpls/libcharls
for x in ../rpm/dcmtk-3.6.0-000*; do patch -p1 < $x; done

the build finishes with no errors.

I hope that will help a bit to fix this package. I would really like to use pacman to manage this one.

All comments