Comments on linking with libtool-1.3.4 under hpux 10.20

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

In examing with chatr how libtool 1.3.4 links shared libraries into apps
under hpux 10.20, I noticed that the +b option to define a search path
for shared libraries was not being used correctly.  These observations
were drawn from examing how the as-new application in binutils-2.9.5
was linked first in the initial build and then again for installation.
Being a believer in keeping things simple, I think libtool should not
use by default the +b option when linking.

Here is the libtool command used to link as-new:

/bin/sh ./libtool --mode=link gcc -W -Wall -O3  -o as-new  app.o as.o atof-generic.o bignum-copy.o cond.o depend.o dwarf2dbg.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o sb.o stabs.o subsegs.o symbols.o write.o tc-hppa.o obj-som.o atof-ieee.o  ../opcodes/libopcodes.la ../bfd/libbfd.la ../libiberty/libiberty.a ./../intl/libintl.a
mkdir .libs
libtool: link: warning: this platform does not like uninstalled shared libraries
libtool: link: `as-new' will be relinked during installation
gcc -W -Wall -O3 -o .libs/as-new app.o as.o atof-generic.o bignum-copy.o cond.o depend.o dwarf2dbg.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o sb.o stabs.o subsegs.o symbols.o write.o tc-hppa.o obj-som.o atof-ieee.o /xxx/gnu/binutils-2.9.5/opcodes/.libs/libopcodes.sl /xxx/gnu/binutils-2.9.5/bfd/.libs/libbfd.sl ../libiberty/libiberty.a ./../intl/libintl.a -Wl,+b -Wl,/xxx/gnu/binutils-2.9.5/opcodes/.libs:/xxx/gnu/binutils-2.9.5/bfd/.libs:/usr/local/lib

# chatr as-new
as-new: 
         shared executable 
         shared library dynamic path search:
             SHLIB_PATH     disabled  second 
             embedded path  enabled   first  /xxx/gnu/binutils-2.9.5/opcodes/.libs:/xxx/gnu/binutils-2.9.5/bfd/.libs:/usr/local/lib
         internal name:
             .libs/as-new
         shared library list:
             static    /xxx/gnu/binutils-2.9.5/opcodes/.libs/libopcodes-2.9.5.sl
             static    /xxx/gnu/binutils-2.9.5/bfd/.libs/libbfd-2.9.5.sl
             dynamic   /usr/lib/libc.1
         shared library binding:
             deferred 
         global hash table disabled
         plabel caching disabled
         global hash array size:1103
         global hash array nbuckets:3
         shared vtable support disabled
         static branch prediction disabled
         kernel assisted branch prediction enabled
         lazy swap allocation disabled
         text segment locking disabled
         data segment locking disabled
         data page size: 4K
         instruction page size: 4K

Things to note are:

1)	libtool sets the embedded path to "/xxx/gnu/binutils-2.9.5/opcodes/.libs:/xxx/gnu/binutils-2.9.5/bfd/.libs:/usr/local/lib" with the +b option.

2)	The search paths for the libopcodes and libbfd libraries are static.
	This means the embedded path lookup is NOT used for these libraries.
	The search path for libc is dynamic.  However, libc is not in
	this path.  The standard version of libc is in /usr/lib.

Thus, using the +b option has not had the intended effect.  The binutils
applications work as long as libopcodes and libbfd continue to be found
in their original location.

According to the ld manpage, +b specifies a search path for libraries
specified with either the -l or -l: option.  In the above, libtool does
not use -l to specify the libopcodes and libbfd libraries.  This is why
the search for these libraries is static.

After installation with relinking, we have:

# chatr /usr/local/bin/as
/usr/local/bin/as: 
         shared executable 
         shared library dynamic path search:
             SHLIB_PATH     disabled  second 
             embedded path  enabled   first  /usr/local/lib
         internal name:
             /tmp/libtool-22516/as-new
         shared library list:
             static    /usr/local/lib/libopcodes-2.9.5.sl
             static    /usr/local/lib/libbfd-2.9.5.sl
             dynamic   /usr/lib/libc.1
         shared library binding:
             deferred 
         global hash table disabled
         plabel caching disabled
         global hash array size:1103
         global hash array nbuckets:3
         shared vtable support disabled
         static branch prediction disabled
         kernel assisted branch prediction enabled
         lazy swap allocation disabled
         text segment locking disabled
         data segment locking disabled
         data page size: 4K
         instruction page size: 4K

The embedded path is now changed to just /usr/local/lib but the shared
library lookup for libopcodes and libbfd is again static (ie., the
search path is not used).

In summary, I think the default should be that embedded path (rpath?)
should be disabled under hpux 10.20.  There is some question as to whether
the binutils package correctly specifies the location of the opcodes and
bfd libraries.  However, since .la forms are used, this involved libtool.
If a dynamic lookup is desirable, then the library command passed to
gcc needs to be in -l or -l: form.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)