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
