[Pkg-octave-devel] Bug#567962: Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4
Thomas Weber
thomas.weber.mail at gmail.com
Tue Feb 2 09:11:57 UTC 2010
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
More information about the Pkg-octave-devel
mailing list