Having trouble with archive libraries in 64-bit 11.11 HP-UX

[MTSU_SAN]

I'm trying to compile openldap in 64-bit mode on HPUX 11.11, and whenever I try to link in an archive library, I get an ABI mismatch, or a Cannot load symbol table--but I've checked the object files and they are definitely ELF 64-bit,and nm lists the symbol tables just fine. Has anyone else had trouble with this, and how did you change the linking?
Here is a sample command and output...
/bin/sh ../..//libtool --mode=link cc -static +DD64 -L/usr/local/lib -
L/usr/local/BerkeleyDB.4.3/lib -o dtest dtest.o liblber.la ../../libraries/lib
lutil/liblutil.a
cc +DD64 -o dtest dtest.o -L/usr/local/lib -L/usr/local/BerkeleyDB.4.3/lib ./.l
ibs/liblber.a ../../libraries/liblutil/liblutil.a
ld: (Warning) Cannot load library symbol table in ./.libs/liblber.a, it might be
missing or corrupted. Skipping library ./.libs/liblber.a.
ld: (Warning) Cannot load library symbol table in ../../libraries/liblutil/liblu
til.a, it might be missing or corrupted. Skipping library ../../libraries/liblut
il/liblutil.a.

Thanks for any help!
c*

[Arunvijai_4]

Hello,

Just to make sure, have you installed all the dependancies like BerkeleyDB, etc.. in 64 bit ?

-Arun

[MTSU_SAN]

Oh yes, and had trouble with each and every dependency! Even the binaries from the software porting sites that say they are 2.0 Risc are all 32-bit, and so I've had to compile everything from scratch.
Thanks for asking.
c*

[Dennis Handly]

Typically if you get "Cannot load library symbol table" it means the archive wasn't created with HP's ar.

You can "fix" this by: ar -rs foo.a

[MTSU_SAN]

Thanks, I did rebuild the symbol table with ar, but I got the same message afterwards...Weird, huh?
c*

[Dennis Handly]

>I did rebuild the symbol table with ar

You used the following?
/usr/ccs/bin/ar -rs foo.a

[Sandman!]

Have you checked if the archive libraries you are trying to link with are all 64-bit. Do an ldd -v on the executable to find out the shared dependencies and post the output.

cheers!

[MTSU_SAN]

Why, yes:
frank3 /usr/local4/openldap-2.3.19 $ cd libraries/liblutil
frank3 /usr/local4/openldap-2.3.19/libraries/liblutil $ file liblutil.a
liblutil.a: archive file
frank3 /usr/local4/openldap-2.3.19/libraries/liblutil $ /usr/ccs/bin/ar -rs liblutil.a
frank3 /usr/local4/openldap-2.3.19/libraries/liblutil $ file *.o
avl.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
base64.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
csn.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
detach.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
entropy.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
fetch.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
getpass.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
getpeereid.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
hash.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
ldif.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
lockf.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
md5.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
passfile.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
passwd.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
sasl.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
setproctitle.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
sha1.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
signal.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
sockpair.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
tavl.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
testavl.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
utils.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
uuid.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)
version.o: ELF-64 relocatable object file - PA-RISC 2.0 (LP64)

Then, running make again:
Entering subdirectory liblutil

Entering subdirectory liblber
cc +DD64 -I../../include -I../../include -I/usr/local/include -I/usr/local/BerkeleyDB.4.3/include -c etest.c
/bin/sh ../..//libtool --mode=link cc -static +DD64 -L/usr/local/lib -L/usr/local/BerkeleyDB.4.3/lib -o etest etest.o liblber.la ../../libraries/liblutil/liblutil.a
cc +DD64 -o etest etest.o -L/usr/local/lib -L/usr/local/BerkeleyDB.4.3/lib ./.libs/liblber.a ../../libraries/liblutil/liblutil.a
ld: (Warning) Cannot load library symbol table in ./.libs/liblber.a, it might be missing or corrupted. Skipping library ./.libs/liblber.a.
ld: (Warning) Cannot load library symbol table in ../../libraries/liblutil/liblutil.a, it might be missing or corrupted. Skipping library ../../libraries/liblutil/liblutil.a.


Same error.

[Dennis Handly]

Can you provide either liblber.a & liblutil.a, whichever is smaller?

[MTSU_SAN]

Sure--liblutil.a is attached

[Sandman!]

Hi Connie,

Typically the mismatched ABI is related to mixing 32/64-bit modes in the same compilation. You checked all your .o (object files) but have you verified with elfdump that all the .a (archive libs) files that you're loading into your executable are indeed 64-bit.

cheers!

[MTSU_SAN]

I never thought of that, because the table was built only from the object files listed, and that is the one being complained of that it cannot load the symbol table. Which option to elfdump tells you if it is a 64-bit archive library?

[Dennis Handly]

Looking at your archive indicates no symbol table at all. (elfdump -f -g)
Were you using -q to create or add to it?

My suggestion about using ar -rs doesn't seem to work.

You need to use ar -qs, or use ranlib(1) to fix your archive.

[Kent Ostby]

This RCEN will give you the syntax you are looking for:

http://www1.itrc.hp.com/service/cki/search.do?category=c0&&mode=id&searchCrit=allwords&docType=EngineerNotes&searchString=TFKBRC00004691

[MTSU_SAN]

Well, now I'm really confused, cause when I run elfdump it is fine...
elfdump -a liblutil.a

liblutil.a:

*** Archive Header ***

Date Uid Gid Mode Size Member Name

liblutil.a[base64.o]:
Mar 14 16:10 2006 105 201 304370 0x2070 base64.o

liblutil.a[csn.o]:
Mar 14 16:10 2006 105 201 304370 0xb78 csn.o

liblutil.a[entropy.o]:
Mar 14 16:10 2006 105 201 304370 0xaf0 entropy.o

liblutil.a[sasl.o]:
Mar 14 16:10 2006 105 201 304370 0x588 sasl.o

liblutil.a[signal.o]:
Mar 14 16:10 2006 105 201 304370 0x838 signal.o



etc..

and
elfdump -f -g liblutil.a
liblutil.a:

liblutil.a[base64.o]:

*** ELF Header ***

Class: ELF-64
Data: Big-endian
OS: HP-UX
ABI Version: 1
Type: REL
Machine: PA-RISC
Version: 1
Entry Addr: 0x0
Program Hdr Offset: 0x0
Section Hdr Offset: 0x1c30
Flags: Wide-mode
Flags: PA2.0
Elf Hdr Size: 0x40
Program Hdr Size: 0x38
Program Hdr Number: 0
Section Hdr Size: 0x40
Section Hdr Number: 17
Section Hdr String Idx: 16

liblutil.a[csn.o]:
... etc...

So, why when you looked at it was it not?
c*

[Dennis Handly]

>now I'm really confused, cause when I run elfdump it is fine...

Basically you are seeing the -a and -f output which is useless for ld. You need to look for the -g output. Use ranlib and you'll see the extra global symbol table.

[MTSU_SAN]

I just ran elfdump -g liblutil.a on the file before and after running ranlib, and I get the same output (none!)
frank3 /usr/local4/openldap-2.3.19/libraries/liblutil $ elfdump -g liblutil.a

liblutil.a:

[Dennis Handly]

>I just ran elfdump -g liblutil.a on the file before and after running ranlib, and I get the same output (none!)

I get -g output on your test .a whether I use /usr/ccs/bin/ranlib or /usr/ccs/bin/ar -qs.

[MTSU_SAN]

Different than just the name of the archive file, like I posted?

[Dennis Handly · Accepted solution]

>Different than just the name of the archive file, like I posted?

Yes, massive amounts of output:
copy.a:
*** Archive Symbol Table ***
1618 lutil_b64_ntop
...

[MTSU_SAN]

OKay, it turns out that when I played with it, I used /usr/ccs/bin/ar or /usr/ccs/bin/ranlib, but when I ran the Makefile, it deleted and recreated with ar or ranlib, which are both links to those files, but they DO NOT work the same:
frank3:[/usr/local4/openldap-2.3.19] # ll /bin/ranlib
lr-xr-xr-t 1 root sys 19 Dec 22 2004 /bin/ranlib -> /usr/ccs/bin/ranlib
frank3:[/usr/local4/openldap-2.3.19] # ll /usr/ccs/bin/ranlib
-r-xr-xr-x 1 bin bin 854 Sep 9 2004 /usr/ccs/bin/ranlib

When I switched libtool to use the full path, now it works. Thanks for all of your help!!! Never would have found something that picky myself...

[MTSU_SAN]

Forgot to close when I posted the solution!

[Dennis Handly]

>it deleted and recreated with ar or ranlib, which are both links to those files, but they DO NOT work the same:

This is not likely, the softlinks should work exactly the same. If you are using a "real" shell, what does whence ranlib or whence ar show?

It will likely show the wrong /usr/local/bin/ version?

So you should make sure that /usr/bin comes before /usr/local/bin/.