--disable-shared --enable-static --disable-dl, etc.

[John W. Eaton]

I just checked in the following changeset on the default branch that
should allow --enable-static to work again, with or without
--enable-shared or --enable-dl:

  http://hg.savannah.gnu.org/hgweb/octave/rev/edc5ec6e949b

The changeset also changes the way Octave, its libraries, and .oct
files are linked on systems where shared libraries do not have to be
linked with all dependencies.  So now on those systems, Octave is
linked only with libraries it uses directly (liboctinterp),
liboctinterp is linked only with libraries it uses directly (liboctave
and a few others), liboctave is linked only with libraries it uses
directly (libcruft and a few others), and libcruft is linked only with
libraries it uses directly, and all the gnulib objects are included in
libcruft.  By default, .oct files are not linked with any extra
libraries (their dependencies should be satisfied when they are loaded
by Octave).

As I understand it, this sort of hierarchical linking does not work on
all systems, so it is still possible for each library to be linked
with more than one level of dependency.  For that to happen, the
automake conditional AMCOND_LINK_ALL_DEPS must be "true" when Octave
is configured.  Currently that is only happening on Windows systems
(where -no-undefined is currently being passed to libtool).  If there
are other systems where libraries need to be linked with all
dependencies, then we can fix the configure script to detect them.
But I would like to preserve the ability to avoid linking every .oct
file with libreadline (for example) on systems where that is not
necessary.

Note that building with --enable-static --disable-shared should work
again, but this will probably not produce a purely static binary with
no external dependencies on most modern systems.  For example, on my
system, it just means that all the Octave sources are compiled into a
single binary, but it still links with shared system libraries:

 $ ldd src/octave
   linux-vdso.so.1 =>  (0x00007fff46d6b000)
   libglpk.so.0 => /usr/lib/libglpk.so.0 (0x00007f093ca1f000)
   libGraphicsMagick++.so.3 => /usr/lib/libGraphicsMagick++.so.3 
(0x00007f093c7b0000)
   libGraphicsMagick.so.3 => /usr/lib/libGraphicsMagick.so.3 
(0x00007f093c289000)
   libqhull.so.5 => /usr/lib/libqhull.so.5 (0x00007f093c036000)
   libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 
(0x00007f093bddd000)
   libfltk_gl.so.1.1 => /usr/lib/x86_64-linux-gnu/libfltk_gl.so.1.1 
(0x00007f093bbbf000)
   libfltk.so.1.1 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.1 
(0x00007f093b910000)
   libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 
(0x00007f093b673000)
   liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007f093aa58000)
   libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007f093a538000)
   libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f
   ...

I'm not sure whether it is actually possible to link a purely static
binary on a modern Debian system.  But I want to be able to preserve
the ability to build Octave without dyanamic linking and shared
libraries for at least a while longer in case there are systems where
this is still needed.

See also this discussion from two years ago:

  
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2009-August/016798.html

Based on that, I'm guessing I just created some problems for OS X
users.  If so, please help me fix them.

jwe