Re: thank you for VTK9 and paraview

[Ben Boeckel <ben.boeckel@kitware.com>]

On Mon, Dec 07, 2020 at 10:42:33 +0100, Mathieu Westphal wrote:
> I've included Ben in the discussion, he may be of more help.
> @Ben Boeckel <ben.boeckel@kitware.com> : These fine folks from Debian are
> having some issues with VTK on specific architectures.

Thanks!

> That being said, we are not specifically testing nor supporting these
> architectures, so fixes may be necessary.
> A more public discussion about it, either on our gitlab [1] or on our
> discourse [2] may be needed.

I'll echo that. Could you please file issues? I suspect other distros
will be hitting these problems too and I'd like to get their input on
any problems as well.

> On Fri, Dec 4, 2020 at 6:10 PM Anton Gladky <gladk@debian.org> wrote:
> > 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
> > ==

Hmm. This seems like a builtin call, no? I'd hope the stdlib would give
us this, but I guess it's like c++filesystem? It looks like we'd need
them for:

    Common/Core
    Common/DataModel
    Filters/Core
    Filters/FlowPaths
    Filters/SMP
    Parallel/Core
    Rendering/OpenGL2
    ThirdParty/ioss
    ThirdParty/loguru
    Wrapping/PythonCore

based on inclusion of `<atomic>`. Is this a libstdc++ thing or would
libc++ need it too?

> > 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’?
> > ==

This looks like a Qt thing? That specific mention was removed in commit
a89d6fa9a70054c7bd1718b58996b290ba06ee7f:

    https://gitlab.kitware.com/vtk/vtk/-/commit/a89d6fa9a70054c7bd1718b58996b290ba06ee7f
    https://gitlab.kitware.com/vtk/vtk/-/merge_requests/3233

Maybe that MR needs backported?

> > Am Fr., 4. Dez. 2020 um 13:04 Uhr schrieb Alastair McKinstry
> > <alastair.mckinstry@sceal.ie>:
> > > 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?

ParaView's typical use cases usually end up requiring the larger address
space so I don't think there's much of a loss for dropping 32bit support
myself. Does popcon have any input?

--Ben