Why is /usr/lib/hpux32 used?

[VAS_1]

I am trying to understand why the libraries in /usr/lib/hpux32 are the default libs used by the linker. If this is due to the LPATH, then what causes LPATH's value, if it has not been set explicitly?

===============================================
$ uname -rs
HP-UX B.11.23
$ model
ia64 hp server rx4640
$ cc -V
cc: HP aC++/ANSI C B3910B A.06.05 [Jul 25 2005]
$ cc hello.c
$ ldd -s -v a.out
find library=libc.so.1; required by a.out
search path=/usr/lib/hpux32:/opt/langtools/lib/hpux32 (RUNPATH)
trying path=/usr/lib/hpux32/libc.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1

find library=libdl.so.1; required by /usr/lib/hpux32/libc.so.1
search path=/usr/lib/hpux32 (RUNPATH)
trying path=/usr/lib/hpux32/libdl.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1

[Sandman!]

Hi,

That's the default linker search path on Itanium (32-bit) based systems. If you had a PA-RISC (32-bit) system then the default library path would be "/usr/lib". You can change the default linker (ld) search path by using the LPATH environment variable or the -L linker option (the latter taking precedence over the former).

If unset LPATH then ld searches the default dir "/usr/lib" for parisc & "usr/lib/hpux32" for itanium. If LPATH is set, ld searches only the dirs specified in LPATH and the default dirs are not searched unless specified in LPATH. To nclude /usr/local/lib in the search path after the default directories, set LPATH as follows:

# export LPATH=/usr/lib:/usr/local/lib

Note the "-L" switch if given to cc has higher priority than LPATH.

cheers!

[VAS_1]

> That's the default linker search path on Itanium (32-bit) based systems.

Hmmm. I thought this machine was 64-bit. If I execute getconf KERNEL_BITS it returns 64. Is there something else I should look at?

[Sandman!]

Might also depend on the whether the C compiler is 32 or 64 bit.

[Sandman!]

Could you post the output of the following commands:

# what cc
# file cc

thanks!

[VAS_1]

$ what `which cc`
/usr/bin/cc:
HP aC++/C for Itanium(R)-based systems B3910B A.06.05 [Jul 25 2005]
$ file `which cc`
/usr/bin/cc: ELF-32 executable object file - IA64

(/usr/bin/cc -> /opt/ansic/bin/cc)

[VAS_1]

I admin a server which successfully compiled some COBOL programs (PeopleSoft). After installing the GNUbase fileset from the TC-OpenSource depot, the compilation fails with this error:

Assembler messages:
Can't open +A64 for reading: No such file or directory
ld: Can't find library or mismatched ABI for -lm
Fatal error.

The LPATH is set in the make file to /usr/lib/hpux64:$LD_LIBRARY_PATH. If I set a library path in the compile command (-L/usr/lib/hpux32) the error message travels down to a different set of (PSoft) libraries.

I would like to understand _why_ the GNUbase install is affecting this.

[Sandman!]

Doing a file on cc shows that it's a 32-bit binary and will by default generate 32-bit objects, unless its behaviour is changed using the +DD64 switch. You can compile the source code in both modes and look inside the created binaries using ldd.

# cc hello.c
# ldd -s -v a.out

Will generate 32-bit objects & link the 32-bit library "usr/lib/hpux32" into a.out.

# cc +DD64 hello.c -o hello64
# ldd -s -v hello64

Will generate 64-bit objects & link the 64-bit library "usr/lib/hpux64" into hello64. Doing a file on a.out & hello64 should show this distinction as well.

cheers!

[Sandman!]

From your last post it looks like 32 and 64-bit modes are mixed in the same compilation which could be causing the error possibly.

LPATH=/usr/lib/hpux64:$LD_LIBRARY_PATH shows a 64-bit library while also providing a 32-bit library to the linker on the command line (-L/usr/lib/hpux32). Note the "-L" option would take precedence over the LPATH environment variable.

Could you post the gcc command line you are using as well as the relevant portion of your makefile which could help in debugging this further. Also, what does LD_LIBRARY_PATH contain.

cheers!

[VAS_1]

>LPATH=/usr/lib/hpux64:$LD_LIBRARY_PATH shows a 64-bit library
>while also providing a 32-bit library to the linker on
>the command line (-L/usr/lib/hpux32). Note the "-L" option would
>take precedence over the LPATH environment variable.

Well, I was the one who forced the -L/usr/lib/hpux32 to see if the LPATH having /usr/lib/hpux64 on it was part of my problem.

I'm really mixing up compilers, (COBOL, HP's ANSI C and gcc), in my tests to see how much additional information I can get during the process.

That being said, the COBOL installation appears to be 64-bit, and I am going to reinstall as 32-bit tomorrow, and then see what happens with the PeopleSoft compile, with and without GNUbase utilities....

This conversation has been most educational for me. Thank you! I will post what happens next.