Arch Linux User Repository

Would it be possible to upgrade this package to 3.6.7 that way I can properly link Orthanc and derivatives? :)

Removed options=(), now it compiles. Sorry for any inconveniences

The PKGBUILD contains

#Currently it's not building otherwise
options=(!buildflags)

which is false, the package builds just fine without overriding buildflags. Please remove this.

Removed -lssl flag.

-lssl LDFLAGS hack is no longer required, you can safely drop it.

libssh was removed from depends in the last update: https://aur.archlinux.org/cgit/aur.git/commit/?h=dcmtk&id=8358be53c7d02d94c6c0020399fbbd69df89cde3

Since libssh isn't a dependency, but -lssh is manually added to LDFLAGS for some reason, I get this:

-- Check for working C compiler: /usr/bin/cc - broken
CMake Error at /usr/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "/usr/bin/cc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/make -f Makefile cmTC_49963/fast && /usr/bin/make  -f CMakeFiles/cmTC_49963.dir/build.make CMakeFiles/cmTC_49963.dir/build
    make[1]: Entering directory '/build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_49963.dir/testCCompiler.c.o
    /usr/bin/cc    -o CMakeFiles/cmTC_49963.dir/testCCompiler.c.o -c /build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_49963
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_49963.dir/link.txt --verbose=1
    /usr/bin/cc -lssh -lz  CMakeFiles/cmTC_49963.dir/testCCompiler.c.o -o cmTC_49963 
    /usr/bin/ld: cannot find -lssh
    collect2: error: ld returned 1 exit status
    make[1]: *** [CMakeFiles/cmTC_49963.dir/build.make:99: cmTC_49963] Error 1
    make[1]: Leaving directory '/build/dcmtk/src/dcmtk-3.6.6/CMakeFiles/CMakeTmp'
    make: *** [Makefile:127: cmTC_49963/fast] Error 2

Removing -lssh from LDFLAGS fixes it.

@jas added your suggestions. And @haawda, thanks for the collaboration.

Update

# Author: Miguel Useche <migueluseche@skatox.com>
# Maintainer: Miguel Useche <migueluseche@skatox.com>
# Contributor: Xiao-Long Chen <chenxiaolong@cxl.epac.to>

pkgname=dcmtk
pkgver=3.6.6
pkgrel=1
pkgdesc="A collection of libraries and applications implementing large parts the DICOM standard"
arch=('i686' 'x86_64')
url="http://dicom.offis.de/dcmtk"
license=('other')
depends=('zlib' 'libpng' 'libtiff' 'libxml2' 'openssl' 'libssh' 'libwrap')
makedepends=('cmake' 'make')
source=("ftp://dicom.offis.de/pub/dicom/offis/software/dcmtk/dcmtk${pkgver//./}/${pkgname}-${pkgver}.tar.gz")
sha512sums=('2bba96eac5908012eec7f510e05e7e426b3f1d2454fcdec056a3de9eb724b04d9d12f3cd0088b1f3be9c32430367600abdf30514d0f62c2f017f7740d1008b63')

#Currently it's not building otherwise
options=(!buildflags)

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"

  # Fix linker flags
  export LDFLAGS="-lssh -lz ${LDFLAGS}"

  # Use CMake instead of autotools (./configure)
  # Must build from the root directory or the man pages won't get installed
  cmake . \
    -DCMAKE_BUILD_TYPE:STRING="Release" \
    -DBUILD_SHARED_LIBS:BOOL=ON \
    -DCMAKE_INSTALL_LIBDIR:PATH=lib \
    -DCMAKE_INSTALL_LIBEXECDIR:PATH=lib \
    -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 \
    -DCMAKE_INSTALL_PREFIX=/usr

  make ${MAKEFLAGS}
}

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  make DESTDIR="${pkgdir}/" install

  # Move configuration files from /usr/etc to /etc
  mv "${pkgdir}/usr/etc/" "${pkgdir}/"

  # Remove empty files (0 length)
  find "${pkgdir}" -type f -empty -exec rm -v {} \;
}

Just curious: Where does the libssh dependency in the PKGBUILD come from? DCMTK doesn't use it. The list of DCMTK's third party dependencies is given here: https://support.dcmtk.org/docs/file_install.html Perhaps consider adding a dependency to libiconv or ICU instead, in case someone needs better character set conversion support than provided by the glibc.

Yes, it works. Also note that installing the directory ${pkgdir}/usr/lib/ [1] is useless, it already exists since make install.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dcmtk#n55

@lahwaacz I removed it. Could you confirm that's ok?

The /etc/ld.so.conf.d/dcmtk.conf file installed by the PKGBUILD [1] is completely useless, since the loader looks into /usr/lib by default...

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dcmtk#n59

Fixed, sorry for the wrong URL.

Failure while downloading ftp://dicom.offis.de/pub/dicom/offis/software/dcmtk/dcmtk363/dcmtk-3.6.4.tar.gz

you could define another variable _pkgver=${pkgver//./} and use it in the source array:

source=("ftp://dicom.offis.de/pub/dicom/offis/software/dcmtk/dcmtk${_pkgver}/${pkgname}-${pkgver}.tar.gz")

The source URL is incorrect: s/dcmtk363/dcmtk364/g

@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?

In file included from /var/cache/pacman/pkg/dcmtk31739/dcmtk/src/dcmtk-3.6.2/dcmjpls/libsrc/djcodecd.cc:37:0:
/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.

Updated to include Fedora's patches.