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: 32
Popularity: 0.047880
First Submitted: 2008-11-07 13:14
Last Updated: 2015-06-21 22:21

Latest Comments

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

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
wget ftp://dicom.offis.de/pub/dicom/offis/software/dcmtk/dcmtk360/dcmtk-3.6.0.tar.gz
wget http://kojipkgs.fedoraproject.org/packages/dcmtk/3.6.0/16.fc20/src/dcmtk-3.6.0-16.fc20.src.rpm
tar -xvzf dcmtk-3.6.0.tar.gz
mkdir rpm
cd rpm
rpmextract.sh ../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

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/libdcmimage.so.3.6.0: undefined reference to `png_create_info_struct'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_write_info'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_write_image'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_set_IHDR'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_destroy_write_struct'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_set_text'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_init_io'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_set_longjmp_fn'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_convert_from_time_t'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_write_end'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_set_tIME'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: undefined reference to `png_create_write_struct'
../../dcmimage/libsrc/libdcmimage.so.3.6.0: 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

@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

/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib

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:

MAKEFLAGS="-j1"

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: http://ompldr.org/vZGdrdg/gcc_4.7_build_fix.patch

and source package: http://ompldr.org/vZGdrdw/dcmtk-3.6.0-1.src.tar.gz

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

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 libdcmdata.so
[ 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

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: http://paste.kde.org/179708/

chenxiaolong commented on 2011-12-31 00:13

Oh yeah, the patches are from this particular Fedora release: http://koji.fedoraproject.org/koji/buildinfo?buildID=277366

chenxiaolong commented on 2011-12-31 00:12

@Skatox: Could you update with this PKGBUILD: http://paste.kde.org/179702/ ? 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

Updated

Anonymous comment on 2010-10-20 15:00

Snapshot 20101008 is out.

Skatox commented on 2010-10-02 13:06

Updated

Skatox commented on 2010-09-30 01:25

I wiil update this pkgbuild this weekend

MartinZ 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, http://forum.dcmtk.org/viewtopic.php?t=2359&sid=4e6fc20080096eeadcae0c4a5597a297 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 tlslayer.cc
tlslayer.cc: In constructor 'DcmTLSTransportLayer::DcmTLSTransportLayer(int, const char*)':
tlslayer.cc:195: error: invalid conversion from 'const SSL_METHOD*' to 'SSL_METHOD*'
tlslayer.cc:198: error: invalid conversion from 'const SSL_METHOD*' to 'SSL_METHOD*'
tlslayer.cc:201: 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