Bug#911793: Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2

[Gert Wollny]

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