[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Installing an executable uses exactly the same command line that I used to install the library earlier:
$ libtool cp hello /usr/local/bin gcc -o /tmp/libtool-28585/hello main.c /usr/local/lib/libhello.sl \ /usr/local/lib/libtrim.sl -Wl,+b -Wl,/usr/local/lib cp /tmp/libtool-28585/hello /usr/local/bin/hello $ /usr/local/bin/hello Hello, World! |
As libtool
said earlier, during the initial linking of the
hello
program in the build directory, hello
must be
rebuilt before installation. This is a peculiarity of HP-UX (and a
few other architectures) which you won’t see if you are following the
examples on a GNU/Linux system. In the shell trace above,
libtool
has built an installable version of the
hello
program, saving me the trouble of remembering (or worse
– coding for) the particulars of HP-UX, which runs correctly from
the installed location.
As a matter of interest, if you look at the attributes of the installed
program using HP-UX’s chatr
command:
$ chatr /usr/local/bin/hello /usr/local/bin/hello: shared executable shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /usr/local/lib internal name: /tmp/libtool-28585/hello shared library list: static /usr/local/lib/libhello.sl.0 static /usr/local/lib/libtrim.sl.0 dynamic /lib/libc.1 shared library binding: deferred ... |
You can see that the runtime library search path for the installed
hello
program has been set to find the installed
‘libhello.sl.0’ shared archive, preventing it from accidentally
loading a different library (with the same name) from the default load
path. This is a feature of libtool
, and a very important one
at that, and although it may not seem like the right way to do things
initially, it saves a lot of trouble when you end up with
several versions of a library installed in several locations, since each
program will continue to use the version that it was linked with,
subject to library versioning rules, see Library Versioning.
Without the help of
libtool
, it is very difficult to prevent programs and libraries in the build tree from loading earlier (compatible) versions of a shared archive that were previously installed without an intimate knowledge of the build hosts architecture. Making it work portably would be nigh impossible! You should experiment with changes to the uninstalled library and satisfy yourself that the previously installed program continues to load the installed library at runtime, whereas the uninstalled program picks up the modifications in the uninstalled version of the library.
Equally importantly, the uninstalled hello
program continues
to load the uninstalled shared archive. This allows me to continue
developing in the source directories and perform test builds in the
knowledge that libtool
has built all of my executables,
including the uninstalled executables in the build tree, to load the
correct version of the library. I can check wth HP-UX’s
chatr
command, like this:
$ libtool --mode=execute chatr ./hello /tmp/hello/.libs/hello: shared executable shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /tmp/intro-hello/.libs:\ /usr/local/lib internal name: .libs/hello shared library list: static /tmp/intro-hello/.libs/libhello.sl.0 static /tmp/intro-hello/.libs/libtrim.sl.0 dynamic /lib/libc.1 shared library binding: deferred ... |
This example introduces the concept of Libtool modes. Most of the time
libtool
can infer a mode of operation from the contents of the
command line, but sometimes (as in this example) it needs to be told.
In Executing Uninstalled Binaries we already used
libtool
in execute mode to run gdb
against an
uninstalled binary. In this example I am telling libtool
that
I want to pass the hello
binary to the chatr
command, particularly since I know that the ‘hello’ file is a
script to set the local execution environment before running the real
binary.
The various modes that libtool
has are described in the
Libtool reference documentation, and are listed in the Libtool help
text:
$ libtool --help ... MODE must be one of the following: clean remove files from the build directory compile compile a source file into a libtool object execute automatically set library path, then run a program finish complete the installation of libtool libraries install install libraries or executables link create a library or an executable uninstall remove libraries from an installed directory MODE-ARGS vary depending on the MODE. Try `libtool --help --mode=MODE' for a more detailed description of MODE. |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Ben Elliston on July 10, 2015 using texi2html 1.82.