On 11/04/2013 22:17, Phil Clayton wrote:
I am also wondering whether libtool helps. I know very little about it
though.
I wonder if --disable-shared should be the default with ./configure. It
would solve a lot of these problems. I can see that packagers who are
going to build a package to install to the standard location would want
to build the shared library but users building a stand-alone system
probably don't want it. If you're only building "poly" anyway there's
no saving by having libpolyml as a separate library.
If, in future, people are building Poly/ML-based applications, I think
it would be preferable for the default to be dynamic. For example, I
have just tried building the (SML!) GTK+ Hello World demo: the
executable is much larger with static linking (768k with -ggdb, 560k
stripped) than with dynamic linking (160k, 148k).
The default linking method is quite a significant decision because, if I
understand correctly, it fixes the way Poly/ML-based applications are
linked, i.e. it is not possible to choose the linking method (to
Poly/ML) when building a Poly/ML-based application. Is that correct? (I
am intrigued to know why.)
I've only used libtool with Poly/ML and as part of autoconf/automake so
I'm far from an expert. In the case of Poly/ML what happens is this.
The default is --enable-shared --enable-static. This builds two
versions of libpolyml; one for dynamic loading, the other static. When
"poly" is linked it uses the dynamic library if it is present, resulting
in an executable that depends on being able to load libpolyml at
run-time. If poly has been linked with the dynamic version of libpolyml
libtool builds a shell script and, within the build directory, it uses
this as "poly". That enables "./poly" within the build directory to
work since this script sets the appropriate library path before running
the actual executable from the ".libs" sub-directory. "make install"
installs the actual executable and the libraries so after installation
running "/installdirectory/poly" requires either the library path to
find libpolyml or for libpolyml to be in a standard place.
If the dynamic version of libpolyml is not present when poly is linked,
probably because --disable-shared has been given, poly will be linked
with the static version of libpolyml. This removes the need to find
libpolyml at run-time. It doesn't affect any other libraries so the C++
libraries, for example, will still be linked dynamically. This is in
contrast with "-static" which links all the libraries statically.
The situation is the same when linking any other object file produced
with PolyML.export. If only the static version of libpolyml is present
there's no need for LD_LIBRARY_PATH at run-time. I think it is possible
to use static linking for specific libraries even if there is a dynamic
version available but it's quite messy. See
http://stackoverflow.com/questions/4156055/gcc-static-linking-only-some-libraries
.
Based on this, I think there would be a case for setting the default for
Poly/ML to be --disable-shared so that producing the dynamic version
requires an explicit option.
David
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
