Arch Linux User Repository

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

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

So it should be a dependency.

Now it is working perfectly for me.

Thanks a lot for the quick fix.

@haawda thanks for the report, updated.

Installs libs to /usr/lib64 for me. Adding

-DCMAKE_INSTALL_LIBDIR:PATH=lib \

-DCMAKE_INSTALL_LIBEXECDIR:PATH=lib

to the cmake command prevents this.

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?

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

"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

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.

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