[ note how I removed 914347 from the recipients and kept only 914483 ] On Fri, Nov 23, 2018 at 09:43:10PM +0100, Gert Wollny wrote: > 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.
Thanks, that one looks good to me.
> > 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).
regardless of that script (I don't particularly like
pkgkde-symbolshelper tbh, also I don't think that script is doing that
much to help…), I notice that the libgdcm2.8 library is indeed not
nice...
I tried to compared the symbols exported between several versions, and
they all differ. And not just from some templates or stuff leaked from
the std library; for example between 2.8.7-1 and 2.8.7-2 stuff like this
disappered from libgdcmDSED.so.2.8:
_ZN10gdcmstrict7DataSet6RemoveERKN4gdcm3TagE@Base
and many others... I haven't looked deep so I couldn't quite understand
where that is coming from, but given that this happens quite frequently
but clearly nothing breaks badly all the time I guess it's just
something that shouldn't have been exported in the first place?
> 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.
If it's only 32/64 bits difference, that's easy to do since there is an
arch-bits filter you can use. But I acknowledge that for many c++
libraries where their developers don't explicitly try to keep their
exported ABI tidy is very easy to get a mess.
This line is from a diff between libgdcm2.8 2.8.7-2 vs 2.8.7-5:
- gdcm::Attribute<(unsigned short)32, (unsigned short)17, 512,
1>::GetAsDataElement() const@Base 2.8.7
+ gdcm::Attribute<(unsigned short)32, (unsigned short)19, 512,
1>::GetAsDataElement() const@Base 2.8.7
That's clearly something that shouldn't have leaked here...
But that kind of things make impossible even thoughts like "I'll keep a
.symbols only for amd64" (which is a valid idea to have).
At the same time, libvtkgdcm is much more tidy, so at least I will start
adding a .symbols file to that one...
> > 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)
Note that here you probably meant DEB_HOST_ARCH, not build arch.
> 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.
ACK, thanks.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
