problem with ld +b when linking on 32-bit HP/UX

[Tim Alsop]

I have discovered a strange problem on HP/UX 11.11 when compiling 32-bit code. The same code, when compiled using +DD64 (64-bit) works correctly.

The ld statement used is shown below :

/usr/bin/ld -ldld +b/krb5/ext/lib:/krb5/appsec-rt/lib:/krb5/lib -b +h libldap-2.3.sl.1 +b /krb5/ext/lib -o .libs/libldap-2.3.sl.1.6
.libs/bind.o .libs/open.o .libs/result.o .libs/error.o .libs/compare.o .libs/search.o .libs/controls.o .libs/messages.o .libs/refer
ences.o .libs/extended.o .libs/cyrus.o .libs/modify.o .libs/add.o .libs/modrdn.o .libs/delete.o .libs/abandon.o .libs/sasl.o .libs/sbind.o .libs/kbind.o .libs/unbind.o .libs/cancel.o .libs/filter.o .libs/free.o .libs/sort.o .libs/passwd.o .libs/whoami.o .libs/getdn.o .libs/getentry.o .libs/getattr.o .libs/getvalues.o .libs/addentry.o .libs/request.o .libs/os-ip.o .libs/url.o .libs/sortctrl.o .libs/vlvctrl.o .libs/init.o .libs/options.o .libs/print.o .libs/string.o .libs/util-int.o .libs/schema.o .libs/charray.o .libs/tls.o .libs/os-local.o .libs/dnssrv.o .libs/utf-8.o .libs/utf-8-conv.o .libs/turn.o .libs/groupings.o .libs/txn.o .libs/ppolicy.o .libs/version.o -L/home/talsop/source/external/cyrussasl/lib/.libs -L/home/talsop/source/external/cyrussasl/plugins/.libs -L/home/talsop/source/external/openldap/libraries/libldap/.libs -L/home/talsop/source/external/openldap/libraries/liblber/.libs -L/home/talsop/source/toolkits/devpack/security-tk/lib -L/home/talsop/source/common/k542/lib ../../libraries/liblber/.libs/liblber.sl /home/talsop/source/external/cyrussasl/lib/.libs/libsasl2.sl -L/krb5/lib -lc -ldld +b/krb5/ext/lib:/krb5/appsec-rt/lib:/krb5/lib

This link works, but when I use this library, at runtime, it expects to find the libsasl2.sl library in /home/talsop/source/external/cyrussasl/lib/.lib directory instead of searching the paths given using +b option.

When I use ldd -s to display the library, I see :

..snip...
find library=/usr/lib/libc.2; required by implicit load
search path=/krb5/ext/lib:/krb5/appsec-rt/lib:/krb5/lib (RPATH)
trying path=/krb5/ext/lib/libc.2
trying path=/krb5/appsec-rt/lib/libc.2
trying path=/krb5/lib/libc.2
trying path=/usr/lib/libc.2 (absolute)
/usr/lib/libc.2 => /usr/lib/libc.2

find library=/home/talsop/source/external/cyrussasl/lib/.libs/libsasl2.sl.2; required by libldap.sl
/home/talsop/source/external/cyrussasl/lib/.libs/libsasl2.sl.2 => /home/talsop/source/external/cyrussasl/lib/.libs/lib
sasl2.sl.2

find library=/usr/lib/libc.2; required by /home/talsop/source/external/cyrussasl/lib/.libs/libsasl2.sl.2
search path=/krb5/ext/lib:/krb5/appsec-rt/lib:/krb5/lib (RPATH)
trying path=/krb5/ext/lib/libc.2
trying path=/krb5/appsec-rt/lib/libc.2
trying path=/krb5/lib/libc.2
search path=/krb5/ext/lib (RPATH)
trying path=/krb5/ext/lib/libc.2
trying path=/usr/lib/libc.2 (absolute)
/usr/lib/libc.2 => /usr/lib/libc.2
..snip..

As you can see in the above output the libsasl2.sl library is found in /home/talsop/... If I remove this file, it does not find the same file in /krb5/ext/lib, but this file is installed into /krb5/ext/lib directory as well as in the original directory where the code was compiled from.

Any ideas ?

The same problem does not occur on HP/UX 11.23 on IA-64, so I tried to apply patches to compiler and also to linker, but the patches made no difference.

[Arunvijai_4]

Hi Tim,

Have you tried exporting SHLIB_PATH and LD_LIB_PATH ? Also, use chatr tool to modify these valuse. Do a # man chatr for more information.

-Arun

[Tim Alsop]

Arun,

Thankyou. I will try chatr and let you know, but I would be happier if I knew why this is not required on same system with the 64-bit code, and also not required on an IA-64 system running HP/UX 11.23.

The output of ldd on the IA-64 system is :

find library=libsasl2.sl.2; required by ./libldap.sl
search path=/krb5/ext/lib:/krb5/appsec-rt/lib:/krb5/lib (RUNPATH)
trying path=/krb5/ext/lib/libsasl2.sl.2
libsasl2.sl.2 => /krb5/ext/lib/libsasl2.sl.2

This is what I expect to see on my PARISC 11.11 system for both 32-bit and 64-bit compiles.

I will let you know if chatr helps.

[Tim Alsop]

I have fixed the problem using chatr, as suggested. I would have liked to fix the compiler, so it is consistent, but at least chatr provides a workaround.

Closing...

Thanks,
Tim