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
