Can't find libX11 on new Itanium box?

[reb]

We are in the process of migrating from 11.0 PA-RISC to 11.23 Itanium. My own code all compiles fine, (but I haven't written any X-windows stuff in over 10 years). Now I'm trying to install CPAN modules into the 32-bit perl that came with the box. When I compile GD, the link fails with "ld: Can't find library or mismatched ABI for -lX11". The ld command from the make is passing "-L/usr/lib/hpux32" and "-lX11".

This machine is reasonably fresh from the factory, so it should be configured well. I haven't had a chance to mess it up yet :^).

There is a /usr/lib/hpux32/libX11.so.1 which symlinks to /usr/lib/hpux32/X11R6/libX11.so.1.

The only way I can get this to compile is to go in as root and make a symbolic link pointing /usr/lib/hpux32/libX11.so to /usrlib/hpux32/libX11.so.1. There is no libX11.so anywhere on the system without the version suffix. (There's a libX11.sl in X11R4, but it's PA-RISC code)

Shouldn't ld be able to locate libX11.so.1 to satisfy this link? Is it really required for me to manually create this link in order to compile stuff for X? Or have I simply overlooked some basic information?

[Steven E. Protter]

Shalom,

Do a chattr on the library on a PA-RISC box and maybe get a clue as to where it comes from.

I think there may have been changes to the library that are in the documentation but you missed them.

I don't like factory configured machines. I always redo them. HP's defaults in many areas are shall we say, unrealistic.

SEP

[Dennis Handly]

>There is a /usr/lib/hpux32/libX11.so.1 which symlinks to /usr/lib/hpux32/X11R6/libX11.so.1.

Hmm, my system has /usr/lib/hpux32/libX11.so

It appears it is simple. If you have not purchased the HP C/aC++ Developer's Bundle, you don't get X11MotifDevKit which contains those symlinks.

>Shouldn't ld be able to locate libX11.so.1 to satisfy this link?

No, it only looks at .so and .sl.

[PeterWolfe]

The X11/Motif libraries are also available
(for free) as part of the HP-UX Developer's
Toolkit on software.hp.com:

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B3394BA

[reb]

Ok - some good info.

1) The linker doesn't locate lib files at bind time with version suffixes. That's what I thought, but since they changed the naming convention from ".sl" to ".so", I wasn't sure.

2) People with working Itanium systems do possess a /usr/lib/libX11.so file. (Did you create that manually, or was it created for you by HPUX or ANSI-C install?)

My problem is not due to a failure to purchase and install the Ansi-C/aCC kit, as we have done that.

I'm not sure what chatr on a PA_RISC box is going to tell me. I know what library it links on PA-RISC - my problem is that the compiler isn't able to find an analogous Itanium library on my new box. I know what library it SHOULD be linking, and I also know how to hack the problem and make it go away.

My real question is, is my system misconfigured (it sounds like it is: bad ANSI-C install maybe?), and if so, how do I fix it? If not, have I performed the correct steps to configure it, and if not, what are the "best practices"? Moreover, where should I have read about this?

[James R. Ferguson]

Hi:

> My real question is, is my system misconfigured (it sounds like it is: bad ANSI-C install maybe?), and if so, how do I fix it? If not, have I performed the correct steps to configure it, and if not, what are the "best practices"? Moreover, where should I have read about this?

This question really goes to the heart of patch management, I think. You should read this document for an understanding of that:

http://docs.hp.com/en/5991-6449/index.html

For keeping your systems up-to-date, I recommend downloading and installing the new SWA (Software Assistant) tool:

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B6834AA

To assess the integrity of your currently installed products and patches, run:

# swverify \*

(or):

# /usr/contrib/bin/check_patches

To *fix* problems (permissinos, ownership, etc.) you can run:

# swverify -F \*

Regards!

...JRF...

[reb]

New info:

I talked to the sysadmin who installed ANSI-C, and he told me that the Motif part of the bundle was skipped, for some reason. He reinstalled it, and now there are symlinks out the wazoo.

Thanks for the help, everyone.

[reb]

Closing the thread - reinstall of ANSI-C solved the problem.

[Dennis Handly]

>my problem is that the compiler isn't able to find an analogous Itanium library on my new box.

(You are confused, it is the linker that links, not compiler. :-)

>he told me that the Motif part of the bundle was skipped, for some reason.

Was was there something in your /var/adm/sw/swinstall.log?

[reb]

> >my problem is that the compiler isn't able to find an analogous Itanium library on my new box.

>(You are confused, it is the linker that links, not compiler. :-)

I very rarely type "ld" at the command prompt. Normally when I link something, I have typed "cc blah blah blah", which calls the linker for me behind the scenes. So I use the term "compiler" to describe that whole process. But yes, of course, the compiler compiles, while the linker links.

>he told me that the Motif part of the bundle was skipped, for some reason.

> Was was there something in your /var/adm/sw/swinstall.log?

No - and that's the first thing I checked. He had told me that something "was skipped" when he did the original install, and when I looked at the swinstall.log file on that system, it only warned about skipping bundles that were already present. Not being a sysadmin, and not having seen the ANSI-C install, I'm not sure what exactly happened, but when he reinstalled it from the CD, it fixed the problem.