I also have problems with vtk9 on armel, armhf and mipsel [1]. On armel and mipsel it fails with:
== /usr/bin/ld: ../../lib/arm-linux-gnueabi/libvtkCommonDataModel-9.0.so.9.0.1: undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status == and on armhf: == /<<PKGBUILDDIR>>/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:240:5: error: ‘QOpenGLFunctions_3_2_Core’ was not declared in this scope; did you mean ‘QOpenGLFunctionsPrivate’? == Adding "-latomic" in the first case did not resolve the problem. armhf-failure was not investigate deeply. @Mathieu, could you please help us from the upstream side to analyze those issues with VTK/Paraview? We are approaching a new stable release soon, it would not be good to drop VTK and Paraview on some architectures. [1] https://buildd.debian.org/status/package.php?p=vtk9 Best regards Anton Am Fr., 4. Dez. 2020 um 13:04 Uhr schrieb Alastair McKinstry <alastair.mckins...@sceal.ie>: > > Hi > > The latest Paraview breaks on 32 bit architectures. Its breaking both on > 32/64 bit code issues > (multiple definitions of int/long prototypes in templates) and memory > exhaustion in compilation. > > Is there much merit in building Paraview for 32-bit platforms or should they > be dropped? > > Alastair > > On 30/11/2020, 02:05, "Drew Parsons" <dpars...@debian.org> wrote: > > Hi Anton and Alastair, just a big thank you for getting VTK-9 and > paraview updated and packaged. They've been hard to manage so it's a > good work you've done. > > Drew > >
