Package Details: gdcm 3.0.12-1

Git Clone URL: https://aur.archlinux.org/gdcm.git (read-only, click to copy)
Package Base: gdcm
Description: a C++ library for DICOM medical files
Upstream URL: http://gdcm.sourceforge.net
Keywords: DICOM Python
Licenses: BSD
Submitter: giniu
Maintainer: tfmoraes
Last Packager: tfmoraes
Votes: 29
Popularity: 0.084053
First Submitted: 2013-01-10 11:55 (UTC)
Last Updated: 2022-04-08 19:40 (UTC)

Latest Comments

tfmoraes commented on 2021-11-25 13:47 (UTC)

Thanks @Dylan14 and @bartus. Updated the package to 3.0.10 and disabled VTK because GDCM is not compiling with support to the last VTK.

Dylan14 commented on 2021-11-14 15:04 (UTC)

The following dependencies are needed: ospray openvr python-mpi4py postgresql-libs boost pdal

Also, compilation fails as CMake can't find OpenVDBConfig.cmake. As the openvdb package provided by Arch does not have this file, we would have to wait until that is fixed upstream. It has been raised as an issue (see https://github.com/AcademySoftwareFoundation/openvdb/issues/1160).

bartus commented on 2021-10-25 08:03 (UTC) (edited on 2021-10-25 08:12 (UTC) by bartus)

Having openjepg2 as makedepends produces a deficient package with missing immediate lib dependency, prohibiting building anything against it because of linker error.

Example insight-toolkit:

[100%] Linking CXX executable ../../../../bin/itkTestDriver
/usr/bin/ld: warning: libopenjp2.so.7, needed by /usr/lib/libgdcmMSFF.so.3.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib/libgdcmMSFF.so.3.0: undefined reference to `opj_create_compress'
/usr/bin/ld: /usr/lib/libgdcmMSFF.so.3.0: undefined reference to `opj_stream_create'

You can quickly examine the such issues by running namcap on the package pkg.tar file

$ namcap gdcm-3.0.9-1-x86_64.pkg.tar.zst
...
gdcm E: Dependency openjpeg2 detected and not included (libraries ['usr/lib/libopenjp2.so.7'] needed in files ['usr/lib/libgdcmMSFF.so.3.0.9'])

Besides openjpeg2 there's no other dependency that needs to be moved from makedepends to depends that I can see.

liamtimms commented on 2021-06-15 13:54 (UTC)

@tfmoraes great work! Thanks!

tfmoraes commented on 2021-06-14 17:59 (UTC)

@liamtimms thanks I also updated gdcm to 3.0.9.

liamtimms commented on 2021-06-14 14:57 (UTC)

FYI GDCM currently will not build with gcc11. It can be fixed by using this commit: https://github.com/malaterre/GDCM/commit/4404b770be337bd0d5d3c2289abfd34426433db2

tfmoraes commented on 2020-12-26 20:15 (UTC)

@geosam what is the error? Are you using the last version of CMake?

geosam commented on 2020-12-26 14:36 (UTC)

-DGDCM_BUILD_SHARED_LIBS:BOOL=ON \

gives error in the compilation. Please disable it.

liamtimms commented on 2020-12-11 17:57 (UTC)

FYI to anyone using this now: building GDCM is currently broken with the current version of cmake (3.19.1). This should be fixed in the next cmake update according to https://bugs.gentoo.org/759271

tfmoraes commented on 2020-05-30 21:01 (UTC)

thanks @bartus. I applied your patch.

bartus commented on 2020-05-30 07:12 (UTC) (edited on 2020-05-30 07:14 (UTC) by bartus)

@tfmoraes: When building with APPLICATIONS some extra makedepends has to be included (tested in chroot with extra-x86_64-build)

git am < <(curl -s http://ix.io/2nMS)

tfmoraes commented on 2020-05-29 15:49 (UTC)

Now it's compiling with applications.

hottea commented on 2019-05-03 04:04 (UTC) (edited on 2019-05-03 04:05 (UTC) by hottea)

any suggestion to build gdcm with -DGDCM_BUILD_APPLICATIONS:BOOL=ON?

bastelfreak commented on 2017-07-29 22:28 (UTC)

Hi, 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 https://ci.virtapi.org/job/Arch_Package_gdcm/13/console

crmullins commented on 2017-07-01 19:31 (UTC)

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

femtomatic commented on 2017-07-01 16:00 (UTC)

Hi, the conflict can be resolved by adding -DGDCM_USE_SYSTEM_OPENJPEG:BOOL=ON to the cmake options. I posted a corrected PKGBUILD here: https://pastebin.com/FVH0R4QC

mkoloberdin commented on 2017-07-01 12:28 (UTC)

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 (UTC)

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. Chris

femtomatic commented on 2016-09-09 14:58 (UTC)

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

crmullins commented on 2016-07-29 14:47 (UTC)

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

yan12125 commented on 2016-07-29 13:53 (UTC)

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 (UTC)

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. Chris

crmullins commented on 2016-03-01 11:33 (UTC)

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]. Chris [1] https://aur.archlinux.org/cgit/aur.git/commit/?h=gdcm&id=97a35e17a8694507a73895f00884b90dd68ad20e [2] https://github.com/malaterre/GDCM/commit/4c06d8fa0a107a03638045f5e0bd0ec11013e70b.patch

manzo commented on 2016-03-01 09:43 (UTC)

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 (UTC)

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. Chris [1] https://ehc.ac/p/gdcm/mailman/message/34836001/ [2] https://github.com/malaterre/GDCM/commit/4c06d8fa0a107a03638045f5e0bd0ec11013e70b

giniu commented on 2015-12-30 21:20 (UTC)

done. Good luck with it :)

crmullins commented on 2015-12-30 21:18 (UTC)

@giniu Sounds great, thanks!

giniu commented on 2015-12-30 21:03 (UTC)

@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 (UTC)

Hi, 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. Thanks, Chris [1] https://gist.github.com/chrismullins/ce051b2b47ade15e6c14

thx1138 commented on 2015-12-07 15:38 (UTC)

Also a dependency: openmpi /usr/sbin/ld: warning: libmpi.so.12, needed by /usr/lib/libvtkIOMPIParallel.so.1, not found (try using -rpath or -rpath-link) /usr/sbin/ld: warning: libmpi_cxx.so.1, needed by /usr/lib/libvtkIOMPIParallel.so.1, not found (try using -rpath or -rpath-link) Thanks everyone.

muefra00 commented on 2015-12-07 12:59 (UTC)

@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/libgl2ps.so', needed by 'bin/gdcm2pnm'. Stop. With gl2ps package installed it works perfectly.

giniu commented on 2015-10-23 18:51 (UTC)

Thanks, I will look into it.

yan12125 commented on 2015-10-23 18:21 (UTC)

A working PKGBUILD for VTK 6.3+GDCM 2.6.0: https://gist.github.com/yan12125/2f0765eb2ef20ac07d35 I follow the ideas listed in http://www.mitk.org/wiki/VTK6_Migration_Guide

neurignacio commented on 2015-09-21 13:13 (UTC)

GDCM 2.6.0 was last updated on 2015-09-03

manzo commented on 2014-12-22 16:33 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

v3l0c1r4pt0r commented on 2014-04-23 17:25 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

The latest builds fine by updating the checksum and version. pkgname=gdcm pkgver=2.4.1 md5sums=('1120f9a5ebcef7df6933ca83545f514d')

ahuillet commented on 2013-08-09 14:18 (UTC)

Build fails here, with: make[2]: *** No rule to make target `/usr/lib64/jvm/java-7-openjdk/jre/lib/amd64/libjawt.so', needed by `bin/libvtkgdcmJava.so'. 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 (UTC)

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 (UTC)

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

SMOG commented on 2013-05-21 17:09 (UTC)

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 (UTC)

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?