Bug#797718: flann: transition may be needed for g++-5 ABIs

[Gilles Filippini]

Control: unblock -1 by 791067

On Tue, 1 Sep 2015 23:02:18 +0100 Simon McVittie  wrote:
> Source: flann
> Version: 1.8.4-4.1
> Severity: important
> Control: block -1 by 791067
> 
> Background[1]: libstdc++6 introduces a new ABI to conform to the
> C++11 standard, but keeps the old ABI to not break existing binaries.
> Packages which are built with g++-5 from experimental (not the one
> from testing/unstable) are using the new ABI.  Libraries built from
> this source package export some of the new __cxx11 or B5cxx11 symbols,
> dropping other symbols.  If these symbols are part of the API of
> the library, then this rebuild with g++-5 will trigger a transition
> for the library.
> 
> In the case of flann, std::string appears in header files that
> get installed, but it seems possible that all instances are inline
> (and hence do not affect the ABI). Someone who knows more C++ than me,
> such as the maintainer, should check whether a transition is needed.
> If in doubt, the safe option is to do the transition anyway (see
> 
> for justification).
> 
> The transition consists of renaming the affected library packages, adding a
> v5 suffix (libflann1.8v5). The SONAME should not be changed.
> 
> These follow-up transitions for libstdc++ are not going through exactly
> the normal transition procedure, because many entangled transitions are
> going on at the same time, and the usual ordered transition procedure
> does not scale that far. When all the C++ libraries on which this library
> depends have started their transitions in unstable if required, this
> library should do the same, closing this bug; the release team will deal
> with binNMUs as needed.
> 
> In the case of flann, if a transition is needed, it looks as though it
> will be necessary to wait for hdf5 (#791067).

No, it doesn't depend on the C++ API of HDF5.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#797718: flann: transition may be needed for g++-5 ABIs

[Gilles Filippini]

On Mon, 07 Sep 2015 08:44:46 +0200 Gilles Filippini  wrote:
> Control: unblock -1 by 791067
> 
> On Tue, 1 Sep 2015 23:02:18 +0100 Simon McVittie  wrote:
> > Source: flann
> > Version: 1.8.4-4.1
> > Severity: important
> > Control: block -1 by 791067
> > 
> > Background[1]: libstdc++6 introduces a new ABI to conform to the
> > C++11 standard, but keeps the old ABI to not break existing binaries.
> > Packages which are built with g++-5 from experimental (not the one
> > from testing/unstable) are using the new ABI.  Libraries built from
> > this source package export some of the new __cxx11 or B5cxx11 symbols,
> > dropping other symbols.  If these symbols are part of the API of
> > the library, then this rebuild with g++-5 will trigger a transition
> > for the library.
> > 
> > In the case of flann, std::string appears in header files that
> > get installed, but it seems possible that all instances are inline
> > (and hence do not affect the ABI). Someone who knows more C++ than me,
> > such as the maintainer, should check whether a transition is needed.
> > If in doubt, the safe option is to do the transition anyway (see
> > 
> > for justification).

I've rebuilt flann locally with a .symbols file and it appears that
libflann1.8 does export cxx11 symbols.

> > 
> > The transition consists of renaming the affected library packages, adding a
> > v5 suffix (libflann1.8v5). The SONAME should not be changed.
> > 
> > These follow-up transitions for libstdc++ are not going through exactly
> > the normal transition procedure, because many entangled transitions are
> > going on at the same time, and the usual ordered transition procedure
> > does not scale that far. When all the C++ libraries on which this library
> > depends have started their transitions in unstable if required, this
> > library should do the same, closing this bug; the release team will deal
> > with binNMUs as needed.
> > 
> > In the case of flann, if a transition is needed, it looks as though it
> > will be necessary to wait for hdf5 (#791067).

The good news is that libflann1.8 doesn't have any reverse dependency. 4
packages (fcl, hugin, ompl, pcl) build-depends on libflann-dev but none
of the resulting binary packages actually depends on libflann1.8.

Then a binnmu for flann should suffice.

> No, it doesn't depend on the C++ API of HDF5.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#797718: flann: transition may be needed for g++-5 ABIs

[Simon McVittie]

Source: flann
Version: 1.8.4-4.1
Severity: important
Control: block -1 by 791067

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of flann, std::string appears in header files that
get installed, but it seems possible that all instances are inline
(and hence do not affect the ABI). Someone who knows more C++ than me,
such as the maintainer, should check whether a transition is needed.
If in doubt, the safe option is to do the transition anyway (see

for justification).

The transition consists of renaming the affected library packages, adding a
v5 suffix (libflann1.8v5). The SONAME should not be changed.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

In the case of flann, if a transition is needed, it looks as though it
will be necessary to wait for hdf5 (#791067).

S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition