|  |  10.7 Installing an Executable 
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 libtoolsaid earlier, during the initial linking of thehelloprogram in the build directory,hellomust 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,libtoolhas built an installable version of thehelloprogram, 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 chatrcommand: 
 |  | $ 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
helloprogram 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 oflibtool, 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 11.4 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. 
This example introduces the concept of Libtool modes.  Most of the time
libtoolcan infer a mode of operation from the contents of the
command line, but sometimes (as in this example) it needs to be told.
In 10.5 Executing Uninstalled Binaries we already usedlibtoolin execute mode to rungdbagainst an
uninstalled binary.  In this example I am tellinglibtoolthat
I want to pass thehellobinary to thechatrcommand, 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 libtoolhas 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.
 | 
 
 |