Package Details: gdcm 2.8.3-10

Git Clone URL: (read-only)
Package Base: gdcm
Description: a C++ library for DICOM medical files
Upstream URL:
Licenses: BSD
Submitter: giniu
Maintainer: crmullins
Last Packager: crmullins
Votes: 21
Popularity: 0.023245
First Submitted: 2013-01-10 11:55
Last Updated: 2017-10-28 02:50

Latest Comments

bastelfreak commented on 2017-07-29 22:28

I'm unable to build this PKGBUILD in a clean archlinux:

-- Checking for module 'libopenjp2'
-- No package 'libopenjp2' found
CMake Error at /usr/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find OpenJPEG: Found unsuitable version "", but required is at
least "2.0.0" (found )
Call Stack (most recent call first):
/usr/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:375 (_FPHSA_FAILURE_MESSAGE)
CMake/FindOpenJPEG.cmake:26 (find_package_handle_standard_args)
CMakeLists.txt:370 (find_package)

I guess there is a makedepend missing? The full buildlog is available at

crmullins commented on 2017-07-01 19:31

Indeed, @femtomatic has the correct fix. PKGBUILD is updated. Thanks all.

femtomatic commented on 2017-07-01 16:00

Hi, the conflict can be resolved by adding -DGDCM_USE_SYSTEM_OPENJPEG:BOOL=ON to the cmake options.

I posted a corrected PKGBUILD here:

mkoloberdin commented on 2017-07-01 12:28

2.8.0-9 fails to install, conflicts with the openjpeg2 package:

error: failed to commit transaction (conflicting files)
gdcm: /usr/lib/pkgconfig/libopenjp2.pc exists in filesystem

$ pacman -Qo /usr/lib/pkgconfig/libopenjp2.pc
/usr/lib/pkgconfig/libopenjp2.pc is owned by openjpeg2 2.1.2-2

crmullins commented on 2016-09-09 15:10

Whoops, thanks @femtomatic. This was actually a stale .SRCINFO, I must have forgotten to re-generate it. The pkgrel should be 6 since this is a version update.


femtomatic commented on 2016-09-09 14:58

Hi, thanks for updating the package, there is a small error in the PKGBUILD pkgrel should be:



crmullins commented on 2016-07-29 14:47

Thanks again for your help @yan12125. This should be fixed.


yan12125 commented on 2016-07-29 13:53

Hi, thanks for updating gdcm to the latest version. Here's a minor issue: The CMake option GDCM_DOCUMENTATION_SKIP_MANPAGES has a different name in version 2.6.4 GDCM_BUILD_DOCBOOK_MANPAGES. I have to change -DGDCM_DOCUMENTATION_SKIP_MANPAGES:BOOL=ON to -DGDCM_BUILD_DOCBOOK_MANPAGES:BOOL=OFF, or I got docbook related errors.

crmullins commented on 2016-03-03 17:22

I see what the problem was:

The patch command was looking two directories up for the patch instead of one -- including the patch in the file index places it in the source dir. Thanks for catching this. Should be fixed now.


crmullins commented on 2016-03-01 11:33

Hi @manzo,

Here is the commit I pushed[1], I'm seeing the patch. Did I push it in the wrong way? When I "Download snapshot" and extract it's included in the tar file, and running makepkg in the directory seems to work. Also yaourt seems to find it.

In the meantime if it's urgent, you can download the patch at [2].



manzo commented on 2016-03-01 09:43

I think you may have missed one file not pushed:

==> Starting prepare()...
patch: **** Can't open patch file ../../skip-manpages.patch : No such file or directory

crmullins commented on 2016-03-01 00:42

Updated to 2.6.3 and ran into this issue [1]. The fix (skipping the manpages) can be accomplished after applying the following patch [2] which looks like it's staged for the 2.7.0 release. Please let me know if anyone has a better idea.



giniu commented on 2015-12-30 21:20

done. Good luck with it :)

crmullins commented on 2015-12-30 21:18

@giniu Sounds great, thanks!

giniu commented on 2015-12-30 21:03

@crmullins Hello! I recently have very limited time for AUR (I barely manage to keep my packages in community up to date). If you want to help maintain this package, I'd be happy to disown it for you, so you can pick up the development. Is it ok?

crmullins commented on 2015-12-30 20:55


I'd like to update this to 2.6.2, and fix some of the dependencies so that other packages like ITK (insight-toolkit) can use it.

Here are the proposed changes[1]. In the future I'd like to work on making some easy options to build with python, java wrapping and vtk bindings. I'd also be happy to help maintain the package. Please let me know what you think.



thx1138 commented on 2015-12-07 15:38

Also a dependency: openmpi

/usr/sbin/ld: warning:, needed by /usr/lib/, not found (try using -rpath or -rpath-link)
/usr/sbin/ld: warning:, needed by /usr/lib/, not found (try using -rpath or -rpath-link)

Thanks everyone.

muefra00 commented on 2015-12-07 12:59

@yan12125 Thanks for the PKGBUILD

It would appear that package by the name of gl2ps is also a dependency:
[100%] Building CXX object Utilities/VTK/Applications/CMakeFiles/gdcm2pnm.dir/gdcm2pnm.cxx.o
make[2]: *** No rule to make target '/usr/lib64/', needed by 'bin/gdcm2pnm'. Stop.

With gl2ps package installed it works perfectly.

giniu commented on 2015-10-23 18:51

Thanks, I will look into it.

yan12125 commented on 2015-10-23 18:21

A working PKGBUILD for VTK 6.3+GDCM 2.6.0:

I follow the ideas listed in

neurignacio commented on 2015-09-21 13:13

GDCM 2.6.0 was last updated on 2015-09-03

manzo commented on 2014-12-22 16:33

Looks like the tar changed:

==> Validating source files with md5sums...
gdcm-2.4.4.tar.bz2 ... FAILED

giniu commented on 2014-11-25 21:41

It is kind of temporary - we are working on updating vtk to 6.1 and it is wasn't tested yet with any packages - vtk5 is exact copy of vtk from community when we started (last version we know that worked). Notice, that in community-staging there is already first version of vtk 6.1.

When ready, vtk at version 6.1 will move to extra from community (as new dependency of opencv) and then I will start checking which vtk packages work with 6.1. Lack of compatibility was sole reason of dropping mayavi from community to AUR and creating legacy vtk5 package.

For now, if you don't want to build vtk5, or if vtk 6.1 works for you, then just update PKGBUILD accordingly. I hope the situation will be resolved soon.

stepo commented on 2014-11-25 21:30

Is there any reason why vtk5 (from AUR) is used as a dependency? I just tried gdcm compiled with modified PKGBUILD where vtk (from community) is used instead of vtk5 and it works fine.

giniu commented on 2014-05-01 15:35

True, I've disabled C# bindings for now. Will look if we can fix them.

v3l0c1r4pt0r commented on 2014-04-23 17:25

Compilation is failing at:
[ 77%] csc *.cs
AssemblyInfo.cs(73,12): warning CS1699: Use compiler option `keyfile' or appropriate project settings instead of `AssemblyKeyFile' attribute
TagSetType.cs(11,27): error CS0246: The type or namespace name `IDisposable' could not be found. Are you missing `System' using directive?
ValuesType.cs(11,27): error CS0246: The type or namespace name `IDisposable' could not be found. Are you missing `System' using directive?
Looks like the workaround is turning off "-DGDCM_WRAP_CSHARP:BOOL" and commenting out "mv *.dll mono/2.0". At least insight-toolkit compiled without that part.

giniu commented on 2014-01-22 18:19

This comes from /usr/lib/vtk-5.10/VTKConfig.cmake - it means, that gdcm should be built using same Java as VTK, and it always means OpenJDK. I will add OpenJDK into build dependencies.

Also, I'm having problems with gcdm picking OpenJPEG2 instead of OpenJPEG and failing, that's why for now I will disable system installed OpenJPEG.

If someone has fixes for those issues, I'd be happy to incorporate them.

giniu commented on 2014-01-20 09:14

Wanted to let you know that I'm working on this, but I'm having same troubles building as ahuillet, I will still try building it using official jdk, but if all tries fail, I will change dependency on java from generic one to openjdk.

snuo commented on 2013-12-13 02:55

The latest builds fine by updating the checksum and version.

pkgname=gdcm pkgver=2.4.1

ahuillet commented on 2013-08-09 14:18

Build fails here, with:
make[2]: *** No rule to make target `/usr/lib64/jvm/java-7-openjdk/jre/lib/amd64/', needed by `bin/'. Stop.
make[1]: *** [Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/all] Error 2

This is with jdk7 (not openjdk). For some reason cmake still picks /usr/lib64/jvm/java-7-openjdk even though that directory doesn't exist.

Adelie commented on 2013-07-19 16:54

using -DGDCM_USE_VTK:BOOL=ON seems to throw build errors even though it install vtk as a dep:

/tmp/yaourt-tmp-dave/aur-gdcm/src/gdcm-2.2.3/Utilities/VTK/vtkgdcm.i:359: Error: Unable to find 'vtkObjectBase.h'
/tmp/yaourt-tmp-dave/aur-gdcm/src/gdcm-2.2.3/Utilities/VTK/vtkgdcm.i:375: Error: Unable to find 'vtkObject.h'

giniu commented on 2013-05-21 19:29

Thanks for letting me know, I will look into it.

SMOG commented on 2013-05-21 17:09

You should add this line in PKGBUILD in the section build(), after the 'cmake \' line:
-DOPENJPEG_INCLUDE_DIR=/usr/include/openjpeg-1.5 \

This fixes the problem I've reported a few hours ago...

SMOG commented on 2013-05-21 16:02

I get an error during build():

CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find OpenJPEG (missing: OPENJPEG_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
CMake/FindOpenJPEG.cmake:39 (find_package_handle_standard_args)
CMakeLists.txt:321 (FIND_PACKAGE)

I've tried to install 'openjpeg' package (by adding it to gdcm depends in PKGBUILD) but the problem remains... do anyone have any hint?

giniu commented on 2013-04-13 17:27

Update is delayed, because for some reason gdcm 2.2.2 and 2.2.3 is picking wrong java on my system (non existing one!). I have to investigate.

giniu commented on 2013-01-10 11:56

I'm merging this package into gdcm (which is newer version and with more bindings)