Comments on linking with libtool-1.3.4 under hpux 10.20
John David Anglin
dave@hiauly1.hia.nrc.ca
Thu May 18 13:29:00 GMT 2000
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)
More information about the Binutils
mailing list