Re: missing info in the models tarballs.

> I decided to try it ..  That is play with it to compile a
> plugin.
>
> It consists of a couple of shell scripts, and some other files
> which are essentially a database of all of the things that need
> configuring.
>
> It has a reasonably good interface, only slightly more
> complicated than just compiling on a single known system.
>
> 1. Compile:
> libtool --mode=compile g++ -c c_list.cc
>
> 2. Link:
> libtool --mode=link g++ c_list.lo -o libc_list.la -rpath /tmp
>
> Now the .so file is hiding in the directory ".libs".

Hi Al,
	The rationale for hiding the shlib in .libs is because there can
be two instances of using it, before installation in the build directory,
and after installation, in its final destination.  When you 'make
install', it will do the necessary re-linking the path if necessary,
depending on platform.  Basically, there should be no need to run libtool
(the one generated by configuration from ltmain.sh) by hand.


> Contrast, without it, but only on a system I know:
> (1 step version)
> g++ -fPIC -DPIC -shared  -o c_list.so c_list.cc
> or (2 step version):
> g++ -fPIC -DPIC -c c_list.cc
> g++ -shared  -o c_list.so c_list.o
>
> Libtool really does this:
> g++ -c c_list.cc  -fPIC -DPIC -o .libs/c_list.o
> g++ -shared   .libs/c_list.o  -lstdc++ -lm -lc -lgcc_s   -Wl,-soname -Wl,libc_list.so.0 -o .libs/libc_list.so.0.0.0
> .. and some other stuff that is almost harmless but not
> necessary.
> ....  essentially the same, but with a few "-l" to load some
> libraries.  These are not necessary, but harmless.
>
> I say "almost" harmless because it does take some space.
>
> So far, looks good.
>
> Looking deeper .....
>
> There are some problems:
>
> 1. It definitely DOES create a run-time dependency.  If we use
> it in this manner, you will need libtool installed to fully run
> gnucap.

No, libtool is never needed as a run-time dependence.  Libtool (./libtool)
is just a self-contained configured script that manages the build and
installation.  If you're thinking of running the libtool script by hand,
you're probably not going about it right way.  Once it installs the
libraries, it's work is done.

When you write plugins (say, as separate packages), they will be
distributed with the same libtool scripts and templates.  The configure
process should be told where the core is installed, and append CPPFLAGS
and LDFLAGS accordingly for the plug-in's build.  The installation of the
plugin's shared libraries will again be managed by libtool (the generated
script).  After installation, libtool has no role in running the
executable or loading plugins.

> Some relief ...  such dependency is only there if you want to
> use source plugins.

Do you mean installing the sources of the plugins?  Is that necessary?

> 2. The libtool tarball is about 3 MB. about 3 times the size of
> the gnucap basic tarball. (core + enough plugins to be useful)
> It contains lots of stuff for lots of systems.

You don't need to ship libtool along with!  Only the few scripts that are
automatically added by libtoolize [--force --copy] are included in the
distribution.  Those are automatically packaged up by automake.  (You can
confirm by running "make distcheck")

Making sense?  (Or am I the one who is confused?)

> What would be nice is a "libtool-light" that does just the two
> features needed here, and has the database organized in such a
> way that it is easy to select and install only the one needed.
>
> The best design of a "libtool-light" is probably 20 or
> so "Make2" files.,or actually not the whole thing, just a few
> defines.  Only one would need to be installed, one small file.

'libtool-light' sounds like those scripts that are included by
libtoolization, not the libtool program itself.

David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
	-- (2400 baud? Netscape 3.0?? lynx??? No problem!)