gdcm @3.0.5_2: build fails on macOS 12 arm64

[bal-agates]

The build fails. See attached log file. The only errors I see seem related to building man pages. It seems to have problems accessing some external xsl includes or have parsing errors. I checked a few files and could manually access the paths so I do not understand. Is something preventing the accesses?

I do have port "docbook-xsl-nons" installed which seems to provide many of the same xsl includes. I also have port "libxslt" installed. I do not have similar port "docbook-xsl-ns" installed but could if needed.

It is curious that the Portfile has variant "docs" commented out with note "installation hangs". I checked CMakeCache.txt and it has

GDCM_DOCUMENTATION:BOOL=OFF
LIBXSLT_EXSLT_INCLUDE_DIR:PATH=/opt/local/include
LIBXSLT_EXSLT_LIBRARY:FILEPATH=/opt/local/lib/libexslt.dylib
LIBXSLT_INCLUDE_DIR:PATH=/opt/local/include
LIBXSLT_LIBRARY:FILEPATH=/opt/local/lib/libxslt.dylib
LIBXSLT_XSLTPROC_EXECUTABLE:FILEPATH=/opt/local/bin/xsltproc

Note that port "docbook-xsl-nons" installs *.xsl under /opt/local/share/xsl/docbook-xsl-nons

[bal-agates]

Port build log

[bal-agates]

cmake cache

[bal-agates]

I was able to build the gdcm applications and libraries using the MacPorts sources but manually running ccmake and make. With some limited testing the applications worked. I know the configuration of the two builds was not identical. I locally modified the port file to make things look as identical as possible but the MacPorts build still failed. Either I have missed something important in the Portfile or the MacPorts build is inheriting some setting that is not obvious.

[bal-agates]

Attached is a Portfile.patch that allowed me to build gdcm for macOS 12 and arm64, both the standard and +applications variant. The primary change was disabling the portion of the build that attempts to build the application man pages with:

-DGDCM_DOCUMENTATION=OFF \
-DGDCM_BUILD_DOCBOOK_MANPAGES=OFF \

So while it builds it will be missing the man pages. I deem those are not essential because most of the command line applications have a "-h" option to get help or you can download detailed help in a PDF from the gdcm homepage. I still do not understand the build problems. It seems related to xsl style sheet paths. I think the source xsl include paths need to get adjusted for the build environment and that is not happening.

I am not sure what other changes I made to the Portfile might be important. Some errors I saw early in the debugging seemed to indicate even when only building the gdcm libraries the C++-14 standard was needed so I eliminated a conditional and set the following for all builds.

compiler.cxx_standard   2014

Is there some benefit to using 2011? Would that allow builds on older macOS?

The original Portfile had the following only in the +application variant so I moved it up to the primary.

-DCMAKE_CXX_STANDARD=14

I am not sure exactly what the compiler.cxx_standard does but it seems likely the CMAKE_CXX_STANDARD=14 is redundant?

I added "depends_lib-append port:ossp-uuid" related to "-DGDCM_USE_SYSTEM_UUID"

I added a bunch of defines to explicity turn off build options. When I ran ccmake manually these were configuration options and I figured it might be clues to someone later if they want to make additional variants that turn on other options.

-DGDCM_BUILD_EXAMPLES=OFF \
-DGDCM_BUILD_TESTING=OFF \
-DGDCM_WRAP_CSHARP=OFF \
-DGDCM_WRAP_JAVA=OFF \
-DGDCM_WRAP_PYTHON=OFF \
-DOPJ_USE_DSYMUTIL=OFF \

The changes here do not address the case sensitive path <CharLS/charls.h> issue of #60696 so I would expect file systems that are case sensitive to still have build issues.

[bal-agates]

Patch for Portfile

[Schamschula (Marius Schamschula)]

In 7390c3b1e6a65c5134ba31a3091b5d6a30bb8241/macports-ports (master):

y

gdcm: update to 3.0.10

Closes: #60697
Closes: #60696
See: #64033