[Pkg-octave-devel] Bug#797992: 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 <smcv at debian.org> [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<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >::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