[Pkg-octave-devel] Bug#567962: Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4

[Thomas Weber]

On Tue, Feb 02, 2010 at 01:06:24AM -0500, John W. Eaton wrote:
> On  1-Feb-2010, Thomas Weber wrote:
> 
> | On Mon, Feb 01, 2010 at 03:59:25PM +0100, Bas Zoetekouw wrote:
> | > Hi!
> | > 
> | > > octave-specfun is currently uninstallable in sid, as it depends on
> | > > libhdf5-1.8.3, while octave3.2 depends on libhdf5-1.8.4.
> | > > Please rebuild octave-specfun against libhdf5-1.8.4.
> | > 
> | > Actually, on further inspection, it seems that there is no need at all
> | > to link against libhdf (and zlib, and libfftw3, and libcurses5, etc).
> | > The package itself doesn't use these symbols, so it shouldn't be linked
> | > against them.
> | > This seems to be an issue for all octave packages, BTW.
> | 
> | Yes. mkoctfile (used to build these files) links them against all
> | libraries that Octave itself uses. I think this has changed in
> | upstream's development version, though.
> 
> No, it hasn't changed.  All .oct files depend on liboctinterp, which
> depends on liboctave and a number of other libraries, and liboctave
> depends on libcruft and a number of other libraries.  So ultimately, a
> .oct file is linked with everything taht Octave is linked with.  I
> don't see that it matters whether this is done directly or
> indirectly, and it seems to be that some systems cannot do the linking
> indirectly, so the dependencies are all listed when the .oct file is
> linked.
> 
> If you have a better solution that is platform neutral and fits
> within the automake+libtool framework, then please start a thread on
> the maintainers at octave.org list.

I don't have a better solution, but I will need to learn some more about
shared libraries anyway for the next major Octave version. So, I'll see
what I can come up with.

	Thomas