Re: DEFUN_DLD link rule

[John W. Eaton]

On 08/30/2013 11:08 AM, Mike Miller wrote:

> Thanks for all of the info. I'll probably leave this alone for now but
> we may want to come back to it later, maybe make the linking of
> libgnu, liboctave, and liboctinterp in oct-files system-dependent.
> It's not that urgent of a problem for me at the moment.

It's OK with me if we trim the list of libraries that we link with,
especially in cases where linking extra libraries causes trouble
(failed linking or something else).

I just tried linking .oct files without the liboctinterp, liboctave,
and $(LIBS) dependencies on my Debian system and linking succeeds with
commands like this:

  /bin/sh ../libtool  --tag=CXX   --mode=link g++ 
-I/usr/include/freetype2     -Wall -W -Wshadow -Wold-style-cast -Wformat 
-Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread 
-avoid-version -module -no-undefined           -o dldfcn/symrcm.la 
-rpath /usr/local/octave/dev/lib/octave/3.7.6+ 
dldfcn/dldfcn_symrcm_la-symrcm.lo -lcholmod -lumfpack -lamd -lcamd 
-lcolamd -lccolamd -lcxsparse

For this command, libtool generates the following command to perform
the actual link:

  libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginS.o 
dldfcn/.libs/dldfcn_symrcm_la-symrcm.o   -lcholmod -lumfpack -lamd 
-lcamd -lcolamd -lccolamd -lcxsparse -L/usr/lib/gcc/x86_64-linux-gnu/4.7 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib 
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -lstdc++ 
-lm -lpthread -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.7/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o  -O2 
-pthread   -pthread -Wl,-soname -Wl,symrcm.so -o dldfcn/.libs/symrcm.so

Note that -lstdc++ -lm -lpthread -lc -lgcc_s are added automatically
by libtool.  Wouldn't these libraries already be linked with Octave at
run time?  Why should libtool add these libraries here?  If I remove
them from the command, linking still succeeds and calling the
resulting .oct file still works, so perhaps even they are not
necessary.

If you do decide to trim the list of libraries, please keep the
ability to link with all dependency libraries as I think that is
necessary for linking a static version of Octave.  However, in that
case, we wouldn't have any .oct files to worry about, so I think this
request only applies to linking liboctave, liboctinterp, and libgui.

FWIW, I don't think I've tried to build a static version of
Octave with llvm and Qt libraries, so I have no idea whether that will
even work.  But I would still like to preserve the possiblity of
building a static version of Octave on systems where that can work.

jwe