Package Details: dcmtk 3.6.7-1

Git Clone URL: (read-only, click to copy)
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: 54
Popularity: 0.46
First Submitted: 2008-11-07 13:14 (UTC)
Last Updated: 2022-05-19 14:14 (UTC)

Latest Comments

wget commented on 2022-05-13 10:46 (UTC)

Would it be possible to upgrade this package to 3.6.7 that way I can properly link Orthanc and derivatives? :)

Skatox commented on 2021-06-23 03:50 (UTC)

Removed options=(), now it compiles. Sorry for any inconveniences

lahwaacz commented on 2021-06-21 07:18 (UTC)

The PKGBUILD contains

#Currently it's not building otherwise

which is false, the package builds just fine without overriding buildflags. Please remove this.

Skatox commented on 2021-06-21 00:46 (UTC)

Removed -lssl flag.

bartus commented on 2021-04-08 06:50 (UTC)

-lssl LDFLAGS hack is no longer required, you can safely drop it.

lahwaacz commented on 2021-04-06 07:26 (UTC)

libssh was removed from depends in the last update:

tavianator commented on 2021-04-05 18:36 (UTC) (edited on 2021-04-05 18:36 (UTC) by tavianator)

Since libssh isn't a dependency, but -lssh is manually added to LDFLAGS for some reason, I get this:

-- Check for working C compiler: /usr/bin/cc - broken
CMake Error at /usr/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler


  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/make -f Makefile cmTC_49963/fast && /usr/bin/make  -f CMakeFiles/cmTC_49963.dir/build.make CMakeFiles/cmTC_49963.dir/build
    make[1]: Entering directory '/build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_49963.dir/testCCompiler.c.o
    /usr/bin/cc    -o CMakeFiles/cmTC_49963.dir/testCCompiler.c.o -c /build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_49963
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_49963.dir/link.txt --verbose=1
    /usr/bin/cc -lssh -lz  CMakeFiles/cmTC_49963.dir/testCCompiler.c.o -o cmTC_49963 
    /usr/bin/ld: cannot find -lssh
    collect2: error: ld returned 1 exit status
    make[1]: *** [CMakeFiles/cmTC_49963.dir/build.make:99: cmTC_49963] Error 1
    make[1]: Leaving directory '/build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp'
    make: *** [Makefile:127: cmTC_49963/fast] Error 2

Removing -lssh from LDFLAGS fixes it.

Skatox commented on 2021-04-03 20:11 (UTC)

@jas added your suggestions. And @haawda, thanks for the collaboration.

haawda commented on 2021-03-22 20:04 (UTC)


# Author: Miguel Useche <>
# Maintainer: Miguel Useche <>
# Contributor: Xiao-Long Chen <>

pkgdesc="A collection of libraries and applications implementing large parts the DICOM standard"
arch=('i686' 'x86_64')
depends=('zlib' 'libpng' 'libtiff' 'libxml2' 'openssl' 'libssh' 'libwrap')
makedepends=('cmake' 'make')

#Currently it's not building otherwise

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"

  # Fix linker flags
  export LDFLAGS="-lssh -lz ${LDFLAGS}"

  # Use CMake instead of autotools (./configure)
  # Must build from the root directory or the man pages won't get installed
  cmake . \

  make ${MAKEFLAGS}

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  make DESTDIR="${pkgdir}/" install

  # Move configuration files from /usr/etc to /etc
  mv "${pkgdir}/usr/etc/" "${pkgdir}/"

  # Remove empty files (0 length)
  find "${pkgdir}" -type f -empty -exec rm -v {} \;

jas commented on 2021-02-04 17:50 (UTC)

Just curious: Where does the libssh dependency in the PKGBUILD come from? DCMTK doesn't use it. The list of DCMTK's third party dependencies is given here: Perhaps consider adding a dependency to libiconv or ICU instead, in case someone needs better character set conversion support than provided by the glibc.

lahwaacz commented on 2019-05-18 10:47 (UTC)

Yes, it works. Also note that installing the directory ${pkgdir}/usr/lib/ [1] is useless, it already exists since make install.


Skatox commented on 2019-05-05 17:15 (UTC)

@lahwaacz I removed it. Could you confirm that's ok?

lahwaacz commented on 2019-01-29 21:53 (UTC)

The /etc/ file installed by the PKGBUILD [1] is completely useless, since the loader looks into /usr/lib by default...


Skatox commented on 2018-12-30 04:13 (UTC)

Fixed, sorry for the wrong URL.

maderios commented on 2018-12-29 11:32 (UTC)

Failure while downloading

haawda commented on 2018-12-26 19:00 (UTC)

you could define another variable _pkgver=${pkgver//./} and use it in the source array:


kinodont commented on 2018-12-26 07:22 (UTC)

The source URL is incorrect: s/dcmtk363/dcmtk364/g

Skatox commented on 2018-03-20 22:07 (UTC)

@haawda updated, it's weird because it didn't asked me to install it.

haawda commented on 2018-03-20 20:46 (UTC)

I happened to not have libwrap installed. The build process wanted to build /usr/lib/libwrap for me...

So it should be a dependency.

farbeiza commented on 2018-03-17 13:08 (UTC)

Now it is working perfectly for me.

Thanks a lot for the quick fix.

Skatox commented on 2018-03-13 12:47 (UTC)

@haawda thanks for the report, updated.

haawda commented on 2018-03-13 07:40 (UTC)

Installs libs to /usr/lib64 for me. Adding



to the cmake command prevents this.

farbeiza commented on 2018-03-12 22:55 (UTC) (edited on 2018-03-12 22:58 (UTC) by farbeiza)

When installing the package, I am getting this error:

error: failed to commit transaction (conflicting files)
dcmtk: /usr/lib64 exists in filesystem
Errors occurred, no packages were upgraded.

I am finding some old posts about a similar problem, but I do not think it is the same problem now.

Is anyone getting something like this?

Skatox commented on 2018-03-12 03:25 (UTC)

Updated to 3.6.3 now it uses included Charls code. No fedora patches.

jas commented on 2018-02-08 21:04 (UTC) (edited on 2018-02-08 21:05 (UTC) by jas)

"The upstream developers should be contacted."

I'm listening ;-) Making our included (and often also modified) versions of the third party libraries interchangable by the ones provided by the OS is something we certainly want to do, but don't quite find the time for. If you were to propose a patch I could at least add it to our issue tracker and maybe someone will find the time to review and finally commit it.

Regarding CharLS we already have this as a feature request:

And we also have:

amos commented on 2018-01-16 14:31 (UTC)

I tried to get it working with charls 2.0, but they changed too much to maintain in downstream patches (names, enums -> enum classes, etc.). The upstream developers should be contacted. In the meantime, I guess the reasonable option is to drop both the patches and the removal of the CharLS they ship. Or depend strictly on CharLS<2.0, but that's probably inconvenient.

Skatox commented on 2018-01-15 16:50 (UTC)

You're right. I have charls1 installed. Should I keep fedora patches or leave it without them?

amos commented on 2018-01-15 16:29 (UTC) (edited on 2018-01-15 16:30 (UTC) by amos)

In file included from /var/cache/pacman/pkg/dcmtk31739/dcmtk/src/dcmtk-3.6.2/dcmjpls/libsrc/
/var/cache/pacman/pkg/dcmtk31739/dcmtk/src/dcmtk-3.6.2/dcmjpls/libsrc/djerror.h:27:10: fatal error: CharLS/interface.h: No such file or directory
 #include "CharLS/interface.h" /* CharLS include */

The fedora patches are for CharLS 1.0, but probably not for CharLS 2.0.

Skatox commented on 2018-01-15 04:57 (UTC)

Updated to include Fedora's patches.

Skatox commented on 2017-07-29 22:33 (UTC)

Updated to stable 3.6.2 version, currently uses bundled charls library. I will wait for Fedora's patches to release a version with Arch's charls.

hoschi commented on 2017-06-14 07:50 (UTC)

[ 57%] Built target dcmdata [ 57%] Linking CXX shared library [ 57%] Built target dcmimage make: *** [Makefile:130: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... *ouch* I want to look at my MRI-Images :(

Skatox commented on 2017-06-05 01:42 (UTC) (edited on 2017-06-05 01:42 (UTC) by Skatox)

Now it throws me SSL errors for depecrated functions. I guess this version cannot be compiled with current libraries. Use snapshot for a newer version. I'm welcome to receive patches to help this to compile.

pmattern commented on 2017-03-08 00:31 (UTC)

@graysky This is probably the problem discussed below as of 2016-11-08.

graysky commented on 2017-02-07 20:02 (UTC)

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: Others?

nisok commented on 2017-01-06 21:29 (UTC)

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

pmattern commented on 2016-12-06 23:09 (UTC)

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 (UTC)

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 (UTC)

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/[.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 (UTC)

@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 (UTC)

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 (UTC)

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

Skatox commented on 2015-01-15 16:25 (UTC)

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

haawda commented on 2014-12-18 21:27 (UTC)

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 (UTC)

I've updated to include a temporary solution.

nylocx commented on 2014-01-21 09:48 (UTC)

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 wget wget 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 cmake -DCMAKE_BUILD_TYPE:STRING="Release"\ -DBUILD_SHARED_LIBS:BOOL=ON \ -DDCMTK_WITH_OPENSSL:BOOL=ON\ -DDCMTK_WITH_PNG:BOOL=ON\ -DDCMTK_WITH_PRIVATE_TAGS:BOOL=ON\ -DDCMTK_WITH_TIFF:BOOL=ON\ -DDCMTK_WITH_XML:BOOL=ON\ -DDCMTK_WITH_CHARLS=ON\ -DDCMTK_WITH_ZLIB:BOOL=ON . make 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.

Skatox commented on 2014-01-04 14:41 (UTC)

There's a problem with latest LIBPNG, I had some problems with Firefox as well but they updated the source code. We'll need to wait until they patch, or set dcmtk to use an older version of libpng, i haven't found how to do it.

mielouk commented on 2013-12-24 21:41 (UTC)

Linking CXX executable dcmcjpeg ../../dcmimage/libsrc/ undefined reference to `png_create_info_struct' ../../dcmimage/libsrc/ undefined reference to `png_write_info' ../../dcmimage/libsrc/ undefined reference to `png_write_image' ../../dcmimage/libsrc/ undefined reference to `png_set_IHDR' ../../dcmimage/libsrc/ undefined reference to `png_destroy_write_struct' ../../dcmimage/libsrc/ undefined reference to `png_set_text' ../../dcmimage/libsrc/ undefined reference to `png_init_io' ../../dcmimage/libsrc/ undefined reference to `png_set_longjmp_fn' ../../dcmimage/libsrc/ undefined reference to `png_convert_from_time_t' ../../dcmimage/libsrc/ undefined reference to `png_write_end' ../../dcmimage/libsrc/ undefined reference to `png_set_tIME' ../../dcmimage/libsrc/ undefined reference to `png_create_write_struct' ../../dcmimage/libsrc/ undefined reference to `png_access_version_number' collect2: error: ld returned 1 exit status dcmjpeg/apps/CMakeFiles/dcmcjpeg.dir/build.make:100: recipe for target 'dcmjpeg/apps/dcmcjpeg' failed make[2]: *** [dcmjpeg/apps/dcmcjpeg] Error 1 CMakeFiles/Makefile2:1745: recipe for target 'dcmjpeg/apps/CMakeFiles/dcmcjpeg.dir/all' failed make[1]: *** [dcmjpeg/apps/CMakeFiles/dcmcjpeg.dir/all] Error 2 Makefile:116: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: dcmtk cleaned

Skatox commented on 2013-09-22 14:28 (UTC)

@zeppelinglg Fixed, thanks for the info.

zeppelinlg commented on 2013-09-21 22:42 (UTC)

Missing cmake make dependency

Skatox commented on 2013-09-18 19:56 (UTC)

@ivan_p Thanks for the report, nobody noticed it in past year. I've updated the PKGBUILD to fix sum512 and updated Fedora's patches to lastest versión.

ivan_p commented on 2013-09-17 22:18 (UTC)

if [[ $(sha512sum ${pkgname}-${pkgver}.tar.gz) != $(sha512sum ${pkgname}-${pkgver}.tar.gz) ]]; This check will always be "successful". Shouldn't one of the checks be on the file inside the fedora/ directory?

cpaulus commented on 2012-09-19 20:45 (UTC)

Seems to work correctly. Thanks !

Skatox commented on 2012-09-13 13:46 (UTC)

Updated to latest Fedora's patches and library is not installed in a separated folder anymore. Please test.

cpaulus commented on 2012-09-13 11:25 (UTC)

I think it would be a good idea. As stated before, some program using dcmtk and cmake won't compile unless you manually specify the lib folder.

Skatox commented on 2012-09-08 14:08 (UTC)

@cpaulus I don't remember the exact reason but some versions ago didn't worked outside dcmtk folder, should i do what do you suggest?

cpaulus commented on 2012-09-08 13:27 (UTC)

Why do you move the libs into a subfolder ? When building a projet that require dcmtk using cmake, it expects the libs to be in /usr/local/lib64 /usr/lib64 /usr/local/lib /usr/lib /usr/local/dicom/lib and not into a "dcmtk" subfolder.

commented on 2012-04-21 21:50 (UTC)

Thanks a lot guys. Your touch fixed it. Arch's fast gcc cycling always gives me trouble.

Skatox commented on 2012-04-21 19:55 (UTC)

Uploaded changes by @chenxiaolong

chenxiaolong commented on 2012-04-21 18:19 (UTC)

I accidentally included: MAKEFLAGS="-j1" in the PKGBUILD. That can be removed to make the build faster.

chenxiaolong commented on 2012-04-21 18:18 (UTC)

@moz, Skatox: It's because of the new gcc 4.7. I'm not sure why errors didn't show up in the logs; it did for me. Anyway, I made a patch that fixes the issue: and source package:

Skatox commented on 2012-04-21 17:29 (UTC)

Have no idea, the error doesn't says too much information.

commented on 2012-04-21 13:33 (UTC)

Hi, my build fails about here. I cant even find a log of the error. Any ideas? [ 20%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrst.o [ 20%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrtm.o [ 20%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrui.o [ 21%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrul.o [ 21%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrulup.o [ 21%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrus.o [ 21%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcvrut.o [ 21%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcxfer.o [ 21%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/dcpath.o [ 22%] Building CXX object dcmdata/libsrc/CMakeFiles/dcmdata.dir/vrscan.o [ 22%] Building C object dcmdata/libsrc/CMakeFiles/dcmdata.dir/vrscanl.o Linking CXX shared library [ 22%] Built target dcmdata make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build dcmtk.

Skatox commented on 2012-01-03 16:05 (UTC)

Updated with chenxiaolong's contribution. Thanks bro.

chenxiaolong commented on 2011-12-31 00:41 (UTC)

Sorry, that PKGBUILD was broken. Here's the good one:

chenxiaolong commented on 2011-12-31 00:13 (UTC)

Oh yeah, the patches are from this particular Fedora release:

chenxiaolong commented on 2011-12-31 00:12 (UTC)

@Skatox: Could you update with this PKGBUILD: ? It uses the patches from Fedora to fix the build and uses external shared CharLS. I've also modified it to use CMake instead of autotools (./configure) since it seems to install the files in better locations (the export line is no longer needed). Although Fedora's patches are used, other distros, like Debian and Ubuntu, are using very similar patches and workarounds to fix the build. Thanks in advance!

Skatox commented on 2011-05-26 13:34 (UTC)

If you change it, you'll need to change the path when you execute the export command after creating the package.

bigpool commented on 2011-05-26 13:32 (UTC)

shall change the default export DCMDICTPATH=/usr/share/dcmtk/dicom.dic in build file?

commented on 2010-12-04 21:31 (UTC)

New snapshot 20101130 is out

Skatox commented on 2010-10-21 02:09 (UTC)


commented on 2010-10-20 15:00 (UTC)

Snapshot 20101008 is out.

Skatox commented on 2010-10-02 13:06 (UTC)


mzecher commented on 2010-09-29 21:54 (UTC)

Snapshot 20100903 is out

Skatox commented on 2010-04-17 13:58 (UTC)

Updated to latest snapshot to avoid compilation errors due to archlinux's openssl.

haawda commented on 2010-04-15 17:44 (UTC)

Does not builsd anymore make[2]: Entering directory `/home/haawda/paketierung/not_maintained_by_me/dcmtk/src/dcmtk-3.5.4/dcmtls/libsrc' c++ -DHAVE_CONFIG_H -DNDEBUG -c -I. -I. -I../include -I../../config/include -I../../ofstd/include -I../../dcmdata/include -I../../dcmnet/include \ -O -I/usr/include/libxml2 -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -march=x86-64 -mtune=generic -O2 -pipe In constructor 'DcmTLSTransportLayer::DcmTLSTransportLayer(int, const char*)': error: invalid conversion from 'const SSL_METHOD*' to 'SSL_METHOD*' error: invalid conversion from 'const SSL_METHOD*' to 'SSL_METHOD*' error: invalid conversion from 'const SSL_METHOD*' to 'SSL_METHOD*' make[2]: *** [tlslayer.o] Error 1 make[2]: Leaving directory `/home/haawda/paketierung/not_maintained_by_me/dcmtk/src/dcmtk-3.5.4/dcmtls/libsrc' make[1]: *** [libsrc-all] Error 2 make[1]: Leaving directory `/home/haawda/paketierung/not_maintained_by_me/dcmtk/src/dcmtk-3.5.4/dcmtls' make: *** [dcmtls-all] Error 2