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-libr... .
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