Am Freitag, den 23.11.2018, 20:14 +0100 schrieb Mattia Rizzolo: > Hi, > > so, if you don't particularly mind, I'm happy to just take the least > and fix all the involved packages here, so src:vtk7 I just uploaded vtk7, I knew where to look because I did the changes that made the libraries go away, and the python thing was not so difficult after all.
> and src:gdcm (and rebuilding fw4spl). At the very least, I'm going > to rename libvtkgdcm2.8 to something else; thinking about > libvtkgdcm2.8a (libvtk7gdcm2.8 would be somewhat against policy, as > it wouldn't match the SONAME anymore, and I don't really like to > change a library's SONAME without coordingation with upstream). Thanks, btw: Mathieu (who proposed the libvtk7gdcm) is actually upstream. > I'd hope the "both vtk6 and vtk7 were loaded in memory" is not so > relevant... after all they are different libraries, they shouldn't > mess with each other that much (there chances of it, but…). The problem is that vtk6 and vtk7 share many symbols, so linking both into the same executable is likely to create problems. [...] > Gert: you mention you gave up on symbols, but at least in gdcm's > changelog I don't see anything about that. Had you had troubles > there as well? TBH I never tried with gdcm, I think I started to upload the package when it was already at version 2.4 and I didn't even note that there is a script for the symbols there (which points at 2.2). When I started packaging some of my software (mia) that has lots of templates I just noted that getting symbols right there is kind of an infinite task because each arch would need its own file because of templates that on 64 bit use some types that are not available, and were not instanciated on 32 bit systems. Maybe the tools are better now, but at that time (2012) it was all kind of wired. > What I would welcome your help with is explaining the camitk FTBFS on > i386. Just had as peek, my guess is that this will help: ifeq ($(DEB_BUILD_ARCH),i386) export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store endif The same was needed for ITK because they write tests with floating point values apparently comparing with high accuracy, and on i386 optimizations can lead to the used of intermediate 80 bit floating point values that then result in test failures because the references were tuned for 64 bit floating point values. Adding above flag makes sure that intermediate results are not keps in these 80 bit FPU registers. Best, Gert