Package Details: dcmtk 3.6.3-3

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: 38
Popularity: 0.524305
First Submitted: 2008-11-07 13:14
Last Updated: 2018-03-20 22:07

Latest Comments

Skatox commented on 2018-03-20 22:07

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

haawda commented on 2018-03-20 20:46

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

Now it is working perfectly for me.

Thanks a lot for the quick fix.

Skatox commented on 2018-03-13 12:47

@haawda thanks for the report, updated.

haawda commented on 2018-03-13 07:40

Installs libs to /usr/lib64 for me. Adding



to the cmake command prevents this.

farbeiza commented on 2018-03-12 22:55

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

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

jas commented on 2018-02-08 21:04

"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

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

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

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

Updated to include Fedora's patches.

Skatox commented on 2017-07-29 22:33

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

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


I want to look at my MRI-Images :(

Skatox commented on 2017-06-05 01:42

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

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

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:


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
> -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.

Skatox commented on 2014-01-04 14:41

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

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().
:: dcmtk cleaned

Skatox commented on 2013-09-22 14:28

@zeppelinglg Fixed, thanks for the info.

zeppelinlg commented on 2013-09-21 22:42

Missing cmake make dependency

Skatox commented on 2013-09-18 19:56

@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

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

Seems to work correctly.

Thanks !

Skatox commented on 2012-09-13 13:46

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

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

@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

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


and not into a "dcmtk" subfolder.

Anonymous comment on 2012-04-21 21:50

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

Uploaded changes by @chenxiaolong

chenxiaolong commented on 2012-04-21 18:19

I accidentally included:


in the PKGBUILD. That can be removed to make the build faster.

chenxiaolong commented on 2012-04-21 18:18

@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

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

Anonymous comment on 2012-04-21 13:33


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().
==> ERROR: Makepkg was unable to build dcmtk.

Skatox commented on 2012-01-03 16:05

Updated with chenxiaolong's contribution. Thanks bro.

chenxiaolong commented on 2011-12-31 00:41

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

chenxiaolong commented on 2011-12-31 00:13

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

chenxiaolong commented on 2011-12-31 00:12

@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

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

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

Anonymous comment on 2010-12-04 21:31

New snapshot 20101130 is out

Skatox commented on 2010-10-21 02:09


Anonymous comment on 2010-10-20 15:00

Snapshot 20101008 is out.

Skatox commented on 2010-10-02 13:06


Skatox commented on 2010-09-30 01:25

I wiil update this pkgbuild this weekend

mzecher commented on 2010-09-29 21:54

Snapshot 20100903 is out

Skatox commented on 2010-04-17 13:58

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

Skatox commented on 2010-04-17 13:39

This is know problem for the DICOM teams, is due to a new version of openssl, it seems the repaired for the internal use and will be released in the next version, inform me if this happens.

haawda commented on 2010-04-15 17:44

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