Package Details: dcmtk 3.6.3-3

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: 38
Popularity: 0.513819
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

-DCMAKE_INSTALL_LIBDIR:PATH=lib \

-DCMAKE_INSTALL_LIBEXECDIR:PATH=lib

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:

http://support.dcmtk.org/redmine/issues/344

And we also have:

http://support.dcmtk.org/redmine/issues/403

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?

All comments