Bug#567962: [Pkg-octave-devel] Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4
Hi John! You wrote: 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. Which platforms in Debian don't support indirect linking? AFAIK, indirect linking is superiour to direct linking if the module in question doesn't use any of the symbols of the library. The current situation exactly shows why: if all modules are explicitly linked to all libraries that octave is linked against, then all of these modules need to be rebuild if the API or ABI of any of octave's dependencies changes (like is the case now with libhdf). This is not only a waste of your own time, but it also complicates library transitions and makes life for the release team more difficult. So, if possible, it would be a good idea not to link against these libraries unless it's really necessary. If you have a better solution that is platform neutral and fits within the automake+libtool framework, then please start a thread on the maintain...@octave.org list. It's simply a matter of only linking against any library you actually use symbols from. Thanks, Bas. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: [Pkg-octave-devel] Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4
On Mon, Feb 08, 2010 at 04:03:20PM +0100, Bas Zoetekouw wrote: Hi John! You wrote: 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. Which platforms in Debian don't support indirect linking? Ehm, when John (he's upstream) talks about different systems, this includes Mac, Windows, BSD, ... Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: [Pkg-octave-devel] Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4
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 maintain...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: needs to be rebuilt against libhdf5-1.8.4
Package: octave-specfun Version: 1.0.8-3 Severity: serious 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. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: needs to be rebuilt against libhdf5-1.8.4
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. Bas. -- +--+ | Bas Zoetekouw | Sweet day, so cool, so calm, so bright, | || The bridall of the earth and skie: | | b...@zoetekouw.net | The dew shall weep thy fall tonight;| +|For thou must die. | +-+ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: [Pkg-octave-devel] Bug#567962: needs to be rebuilt against libhdf5-1.8.4
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. In other words, I won't change that behaviour in Debian. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: [Pkg-octave-devel] Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4
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 maintain...@octave.org list. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
