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 <[email protected]> : 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 <[email protected]> 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 > > <[email protected]>: > > > 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
