Re: thank you for VTK9 and paraview
On Tue, Dec 15, 2020 at 23:36:52 +0200, Adrian Bunk wrote:
> On Tue, Dec 15, 2020 at 09:53:26PM +0100, Anton Gladky wrote:
> >...
> > For GLES-compilation 4 patches were backported [2]-[5].
> >...
> > [5]
> > https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/83_allow_gles_platforms.patch
> >...
>
> Note that this is not a backport:
> From: Adrian Bunk
> Subject: HACK: QVTKOpenGLWindow.cxx: Define GL_BACK_{LEFT,RIGHT} for
>Qt with OpenGL ES
>
> I failed to find a proper fix to backport, and this was my hack for the
> last remaining build issue.
>
> It is not a correct fix, and it would be appreciated if you could look
> into doing that properly.
Could you please file an issue?
--Ben
Re: thank you for VTK9 and paraview
On Tue, Dec 15, 2020 at 09:53:26PM +0100, Anton Gladky wrote:
>...
> For GLES-compilation 4 patches were backported [2]-[5].
>...
> [5]
> https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/83_allow_gles_platforms.patch
>...
Note that this is not a backport:
From: Adrian Bunk
Subject: HACK: QVTKOpenGLWindow.cxx: Define GL_BACK_{LEFT,RIGHT} for
Qt with OpenGL ES
I failed to find a proper fix to backport, and this was my hack for the
last remaining build issue.
It is not a correct fix, and it would be appreciated if you could look
into doing that properly.
> Best regards
>
> Anton
cu
Adrian
Re: thank you for VTK9 and paraview
Hi, Ben, Matthieu thanks for your advices! It seems we have managed to compile vtk9 builds for most of platforms [1] (thanks to Adrian for that!). For GLES-compilation 4 patches were backported [2]-[5]. And for armel, armhf and mips issues this commit [6] did a trick. If you plan to release the next minor vtk9 version with those fixes inside, it would be reasonable for us to upload this version, dropping patches. Thanks again for assistance! [1] https://buildd.debian.org/status/package.php?p=vtk9 [2] https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/80_allow_gles_platforms.patch [3] https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/81_allow_gles_platforms.patch [4] https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/82_allow_gles_platforms.patch [5] https://salsa.debian.org/science-team/vtk9/-/blob/master/debian/patches/83_allow_gles_platforms.patch [6] https://salsa.debian.org/science-team/vtk9/-/commit/381ea980c87793d04005908d2ac08609ded68982 Best regards Anton Am Mo., 7. Dez. 2020 um 16:18 Uhr schrieb Ben Boeckel : > > 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 : 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.
Re: thank you for VTK9 and paraview
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 : 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 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 ``. Is this a libstdc++ thing or would libc++ need it too? > > and on armhf: > > > > == > > /<>/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 > > : > > > 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
Re: thank you for VTK9 and paraview
Hi All, I've included Ben in the discussion, he may be of more help. @Ben Boeckel : These fine folks from Debian are having some issues with VTK on specific architectures. 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. Best, [1]: https://gitlab.kitware.com/vtk/vtk/ [2]: https://discourse.vtk.org/ Mathieu Westphal ParaView Expert Engineer Kitware Europe https://www.kitware.eu/ Please try F3D, A fast and minimalist 3D viewer. https://kitware.github.io/F3D/ On Fri, Dec 4, 2020 at 6:10 PM Anton Gladky 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 > == > > and on armhf: > > == > /<>/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 > : > > > > 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" 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 > > > > >
Re: thank you for VTK9 and paraview
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: == /<>/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 : > > 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" 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 > >
Re: thank you for VTK9 and paraview
Tricky question, hard to be definitive. Certainly you'll want to file a bug upstream in any case and maybe they'll get round to sorting it out. Obviously it'd be nice to have if it's possible to have. Maybe someone might be setting up a controller for some instrument with the microcontroller based on i386 or armhf to reduce costs, and they want to use paraview for some low resolution representation of the data collected. But if we just can't do it, then I think it's not constructive to halt the upgrade for the 64-bit arches. i.e. go ahead and drop 32-bit if there's no reasonable hope of getting it built. There's a bit of precedence with this, with packages dependent on CGAL (pygalmesh, mshr) not building on all arches. Drew On 2020-12-04 20:04, Alastair McKinstry wrote: 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" 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
Re: thank you for VTK9 and paraview
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" 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
