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.mckinstry@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" <dparsons@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
>
>