use of libtool for linking executables - rpath problem

[Bruno Haible]

Dear libtool gurus,

More and more GNU packages start using shared libraries. One example is
libintl (from the GNU gettext package), which installs itself as a shared
library by default now. It is used by many other packages, like textutils,
gcc, hello, and others, which don't use libtool.

For users of Linux distributions, there is no problem, because the libraries
get installed in /usr/lib, which is in the dynamic linker's search path.
But for all other users, who use --prefix - and this includes most non-Linux
users - the created executables don't run because they refer to a library
located in $(prefix)/lib but $(prefix)/lib is not in the dynamic linker's
search path.

Example: First configure and install gettext-0.10.40 with --prefix=${prefix}.
Set CFLAGS="-I${prefix}/include", LDFLAGS="-L${prefix}/lib", then
configure and install hello-1.3.33 or tar-1.3.25 or textutils-2.0.16 or ...

(The CFLAGS and LDFLAGS settings are set by hand here, but could also
come from a configure argument --with-libintl-prefix=${prefix} or from
'libintl-config' shell script.)

I can see six possible approaches:

1) We don't change our packages. We only tell the user that he should have
   used LDFLAGS="-L${prefix}/lib -rpath ${prefix}/lib".

2) Introduce a --with-libintl-prefix that sets LDFLAGS to include the
   -rpath option.

3) Introduce a libintl-config script that sets outputs the right -L and
   -rpath option.

4) Create a stripped-down minilibtool.sh and minilibtool.m4 which serve
   the purpose of linking an executable will all kinds of libraries
   (static libraries, shared libraries, installed libtool libraries).
   Add it to each package that needs to link against a shared library
   (starting with GNU hello, textutils etc.)

5) Add ltmain.sh and libtool.m4 to each package that needs to link against
   a shared library (starting with GNU hello, textutils etc.)

6) Let each package search for 'libtool' in $PATH and use it if found,
   and fall back to 1) if not found.


Evaluation of the approaches:

1) This pushes the problem back to the user. It leads the "configure"
   philosophy ad absurdum: the user has to know/guess in advance which
   libraries the package will need, and set the CFLAGS and LDFLAGS
   accordingly. He also has to have platform dependent knowledge about
   -rpath, "-Wl,-rpath", -R and similar.
   Furthermore, all created executables will get the -rpath, even those
   that don't need it (not only those that depend on a library in that
   particular directory).

2),3) First, would this work at all? I can see in ltmain.sh some code
   to remove duplicate occurrences from the -rpath element list, and
   (for HP-UX, OSF/1 and AIX) code to merge multiple -rpath values
   into a single one, colon-separated. Is this a requirement or only
   an optimization?
   Assuming it is only an optimization, this could work, but the autoconf
   macro for setting LDFLAGS, or - in case 3 - the code which generates
   the libintl-config script - would have to include all the platform
   dependent knowledge about -rpath handling, approx. 20 KB or 30 KB
   of code.
   Who is going to maintain this code, given that is has large overlap
   with libtool?

3) In this case, moreover, the libintl-config script must cope with the
   possibility that the C compiler it is invoked for is different from
   the one which was used to compile the libintl package. Care with ${wl}...

4) The size of minilibtool.sh is ca. 35 KB (= 25% of ltmain.sh), and the
   size of minilibtool.m4 is ca. 64 KB (= 50% of libtool.m4). This is
   definitely smaller than libtool. But who is going to maintain this?
   And is it worth it at all, given that more package will start using
   the -dlopen and other features, which precisely make libtool so big?

5) This is the most easy solution, but increases the package's size by
   470 KB: 3 x 110 KB (libtool.m4, aclocal.m4, configure), 140 KB
   (ltmain.sh). Also, it runs counter to the Libtool manual, which says:

    "If you choose at this point to "install" the library (put it in a
     permanent location) before linking executables against it, then you
     don't need to use libtool to do the linking.  Simply use the
     appropriate `-L' and `-l' flags to specify the library's location."

6) This works only when the same C compiler is used to build the package
   as was used to configure libtool.


Which approach would you libtool guys recommend?

Can you make and maintain a smaller version of libtool.m4 and ltmain.sh
that creates only executables and assumes none of the needed libraries uses
-dlopen or -dlpreopen?

Bruno