Arch Linux User Repository

anyways it should be reasonable to disable this module for now

-DVTK_MODULE_ENABLE_VTK_IOExportPDF=NO

I dont see how it would link to static libs since mingw-w64-libharu only provides shared libs

in the CMakeCache I can read:

LibHaru_LIBRARY_RELEASE:FILEPATH=/usr/i686-w64-mingw32/lib/libhpdf.dll.a

whats the output of "pacman -Ql mingw-w64-libharu" on your side ?

I've solved the problem. The error message undefined reference to_imp__HPDF_Page_GSave@4'contains the key to the solution: the prefix_imp__` means MinGW is attempting to link a static library, but the functions are exported as if it's a dynamic library.

This is different from the existing bug that was already fix in my previous link, which fixed the link failure when libharu is dynamically linked.

In conclusion, when libharu is dynamically linked, the macro HPDF_DLL must be set, but when libharu is statically linked, HPDF_DLL must be unset.

This is actually what VTK-9.2.2/ThirdParty/libharu/CMakeLists.txt tries to do. But for some reason, it's not working properly. To solve this problem, my hack is to remove the check and always set HPDF_DLL to 0. I call this patch libharu-force-static-noexport.patch.

diff -upr VTK-9.2.2/ThirdParty/libharu/CMakeLists.txt VTK-9.2.2.patched/ThirdParty/libharu/CMakeLists.txt
--- VTK-9.2.2/ThirdParty/libharu/CMakeLists.txt 2022-10-02 11:37:19.000000000 +0000
+++ VTK-9.2.2.patched/ThirdParty/libharu/CMakeLists.txt 2023-05-11 04:28:54.626000000 +0000
@@ -13,9 +13,6 @@ include(vtkDetectLibraryType)
 vtk_detect_library_shared(vtklibharu LibHaru::LibHaru)

 set(HPDF_DLL 0)
-if (WIN32 AND vtklibharu_is_shared)
-  set(HPDF_DLL 1)
-endif ()

 configure_file(
   "${CMAKE_CURRENT_SOURCE_DIR}/vtk_libharu.h.in"

After applying this patch, VTK can be built successfully. To solve the problem, just apply this patch for now.

But ultimately, a proper fix instead of a hack should be upstreamed. I don't know why MinGW is attempting to link statically, and I don't know how it's achieved, I don't see any special option to CMake - is it set in some environmental variable or configuration files of the MinGW toolchains themselves? I don't know much about CMake, MinGW, or ArchLinux's MinGW distribution, I'll left the analysis to a real MinGW expert...

Unfortunately, I just found the build is still broken at link time with a massive number of undefined reference errors related to HPDF, because some DLL functions aren't exported correctly by upstream code.

A similar problem was apparently already reported and fixed 5 years ago at upstream: https://gitlab.kitware.com/vtk/vtk/-/issues/17074

But it still appears broken. Perhaps they fixed native build but cross-compile was not fixed properly, or perhaps it's a regression.

The error messages were:

[99%] Linking CXX shared library ../../bin/libvtkIOExportPDF-9.2.dll
[...]
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0x2dc): undefined reference to `_imp__HPDF_Page_GSave@4'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0x30a): undefined reference to `_imp__HPDF_Page_Rectangle@20'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0x31c): undefined reference to `_imp__HPDF_Page_Clip@4'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0x333): undefined reference to `_imp__HPDF_Page_EndPath@4'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0x34a): undefined reference to `_imp__HPDF_Page_GRestore@4'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0x442): undefined reference to `_imp__HPDF_Shading_AddVertexRGB@28'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0xe12): undefined reference to `_imp__HPDF_Page_GSave@4'
/usr/lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld: CMakeFiles/IOExportPDF.dir/objects.a(vtkPDFContextDevice2D.cxx.obj):vtkPDFContextDevice2D.cxx:(.text+0xe32): undefined reference to `_imp__HPDF_Page_GRestore@4'

it should be a bit better now, eventough its not fully tested

This package mingw-w64-vtk 9.2.2-1 is current broken. First, some dependencies are missing, and they need to be installed manually:

• mingw-w64-exprtk
• mingw-w64-cgns
• mingw-w64-verdict

Then it also needs this patch: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9981

Problem 1

vtk's exprtk detection has another bug, it fails to find exprtk even if it has been manually installed:

-- Could NOT find ExprTk: (Required is at least version "2.7") (found /usr/i686-w64-mingw32/include)
CMake Error at CMake/vtkModule.cmake:4578 (message):
  Could not find the ExprTk external dependency.
Call Stack (most recent call first):
  CMake/vtkModule.cmake:5172 (vtk_module_find_package)
  CMake/vtkModule.cmake:5043 (vtk_module_third_party_external)
  ThirdParty/exprtk/CMakeLists.txt:1 (vtk_module_third_party)

Apparently, it's caused by a buggy version check in the build system that didn't handle the Knuth versioning "2.718..." in ExprTk.

The upstream patch is: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9981

For now, to fix the problem, change PKGBUILD to:

source=(
        "https://www.vtk.org/files/release/${pkgver:0:3}/VTK-${pkgver}.tar.gz"
        "https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9981.patch"
)
sha256sums=(
        '1c5b0a2be71fac96ff4831af69e350f7a0ea3168981f790c000709dcf9121075'
        '477ff721d89b8a77a6bdee53549f0012d91891bdd72fdafff1c02b26e27bfede'
)

_architectures="i686-w64-mingw32 x86_64-w64-mingw32"

prepare() {
  cd "${srcdir}/VTK-${pkgver}"
  patch --forward --strip=1 --input="${srcdir}/9981.patch"
}

Problem 2

Then it cannot find cgns:

-- Could NOT find CGNS: Found unsuitable version "CGNS_VERSION-NOTFOUND", but required is at least "4.10" (found CGNS_INCLUDE_DIR-NOTFOUND)
CMake Error at CMake/vtkModule.cmake:4578 (message):
  Could not find the CGNS external dependency.
Call Stack (most recent call first):
  CMake/vtkModule.cmake:5172 (vtk_module_find_package)
  CMake/vtkModule.cmake:5043 (vtk_module_third_party_external)
  ThirdParty/cgns/CMakeLists.txt:9 (vtk_module_third_party)

So mingw-w64-cgns needs to be installed manually.

Problem 3

Then it cannot find verdict:

CMake Warning at CMake/vtkModule.cmake:4572 (find_package):
  By not providing "FindVerdict.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Verdict", but
  CMake did not find one.

  Could not find a package configuration file provided by "Verdict"
  (requested version 1.4.0) with any of the following names:

    VerdictConfig.cmake
    verdict-config.cmake

  Add the installation prefix of "Verdict" to CMAKE_PREFIX_PATH or set
  "Verdict_DIR" to a directory containing one of the above files.  If
  "Verdict" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  CMake/vtkModule.cmake:5172 (vtk_module_find_package)
  CMake/vtkModule.cmake:5043 (vtk_module_third_party_external)
  ThirdParty/verdict/CMakeLists.txt:1 (vtk_module_third_party)


CMake Error at CMake/vtkModule.cmake:4578 (message):
  Could not find the Verdict external dependency.
Call Stack (most recent call first):
  CMake/vtkModule.cmake:5172 (vtk_module_find_package)
  CMake/vtkModule.cmake:5043 (vtk_module_third_party_external)
  ThirdParty/verdict/CMakeLists.txt:1 (vtk_module_third_party)

So mingw-w64-verdict needs to be installed manually.

mingw-w64-cairo also has another massive dependency loop, which can be broken via mingw-w64-cairo-bootstrap.

To break mingw-w64-freetype2's circular dependency, first install mingw-w64-freetype2-bootstrap, then install mingw-w64-freetype2.

[opens@archlinux ~]$ pacaur -S mingw-w64-vtk :: Package mingw-w64-vtk not found in repositories, trying AUR... :: resolving dependencies... tsort: -: input contains a loop: tsort: mingw-w64-cairo tsort: mingw-w64-librsvg tsort: mingw-w64-pango tsort: mingw-w64-harfbuzz tsort: -: input contains a loop: tsort: mingw-w64-cairo tsort: mingw-w64-librsvg tsort: mingw-w64-pango tsort: -: input contains a loop: tsort: mingw-w64-poppler tsort: mingw-w64-cairo tsort: -: input contains a loop: tsort: mingw-w64-harfbuzz tsort: mingw-w64-freetype2 :: dependency cycle detected