Package Details: dcmtk 3.6.8-1

Git Clone URL: https://aur.archlinux.org/dcmtk.git (read-only, click to copy)
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: 54
Popularity: 0.000001
First Submitted: 2008-11-07 13:14 (UTC)
Last Updated: 2024-02-25 14:45 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

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

[ 57%] Built target dcmdata [ 57%] Linking CXX shared library libdcmimage.so [ 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: https://gist.github.com/graysky2/7a23b4cf1c88bfe61be96fd0ec51f678 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/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 (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 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.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »