Le vendredi 04 septembre 2015 à 12:57 +0200, Rafael Laboissiere a écrit : > * Simon McVittie <s...@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