Bug#797992: octave: ABI transition needed for libstdc++ v5

[Simon McVittie]

On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:
> Looking at the C++ library build-dependencies of octave, it is
> waiting for hdf5 (#791067) but everything else seems to be ready.

Looking more closely at this, hdf5 has both a C and a C++ API,
and octave appears to only use the C. If this is correct, then it does
not need to wait for hdf5 after all.

Regards,
S

Bug#797992: octave: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: octave
Version: 4.0.0-3
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
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 octave, std::string appears in functions in
installed headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the affected library
packages, adding a v5 suffix (liboctave3v5). The actual SONAME should
not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, please avoid doing this unless the new upstream version
is extremely low-risk: this transition has been going on for 1 month
already, and anything that drags it out further is bad for Debian.

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.

Looking at the C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.
When hdf5 starts its transition, please give octave a versioned
build-dependency on the version of libhdf5-dev corresponding to
the rename.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Bug#797992: [Pkg-octave-devel] Bug#797992: octave: ABI transition needed for libstdc++ v5

[Rafael Laboissiere]

* Simon McVittie  [2015-09-04 10:16]:


On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:

Looking at the C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.


Looking more closely at this, hdf5 has both a C and a C++ API, 
and octave appears to only use the C. If this is correct, then it does 
not need to wait for hdf5 after all.


The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
a rebuild really necessary?


Rafael

Bug#797992: [Pkg-octave-devel] Bug#797992: Bug#797992: octave: ABI transition needed for libstdc++ v5

[Sébastien Villemot]

Le vendredi 04 septembre 2015 à 12:57 +0200, Rafael Laboissiere a
écrit :
> * Simon McVittie  [2015-09-04 10:16]:
> 
> > On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:
> >> Looking at the C++ library build-dependencies of octave, it is
> >> waiting for hdf5 (#791067) but everything else seems to be ready.
> >
> > Looking more closely at this, hdf5 has both a C and a C++ API, 
> > and octave appears to only use the C. If this is correct, then it does 
> > not need to wait for hdf5 after all.
> 
> The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
> depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
> a rebuild really necessary?

I confirm that the problem described by Simon is real, and that a
transition is needed.

For example, using octave (4.0.0-3) and octave-optim (1.4.1-1) from
unstable, one gets:

octave:1> numhessian
error: 
/usr/lib/x86_64-linux-gnu/octave/packages/optim-1.4.1/x86_64-pc-linux-gnu-api-v50+/numhessian.oct:
 failed to load: 
/usr/lib/x86_64-linux-gnu/octave/packages/optim-1.4.1/x86_64-pc-linux-gnu-api-v50+/numhessian.oct:
 undefined symbol: _ZNK5ArrayISsE17resize_fill_valueEv

The problematic symbol is:

$ c++filt _ZNK5ArrayISsE17resize_fill_valueEv
Array >::resize_fill_value() const

It has indeed to do with std::string.

Simon: I should take care of uploading a fixed octave package this
week-end (provided that HDF5 is indeed not a blocker). But feel free to
NMU if I don't act quickly enough.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594