SHLIB_PATH and -L with perl modules

[reb]

Can someone explain to me why sometimes I can build a perl module and it remembers where the libraries are (from the -L option), while other times I need to set SHLIB_PATH to get it to work?

I'm installing CPAN modules into the perl_32 that came on my new Itanium boxes. Running HPUX 11.23. I can compile, install, and run DBD::Oracle (for instance) just fine without having to set SHLIB_PATH=/oracle/lib. (and I would think that would be the acid test...)

But, for some reason, the perl-shared binding of rrdtool won't find libz.so unless I set SHLIB_PATH=/usr/local/lib/hpux32, even though I patched the Makefile.PL to set '-L /usr/local/lib/hpux32'.

The GD module also has a problem finding the libs in /usr/local/lib/hpux32 without SHLIB_PATH.

Am I doing something wrong?

[Steven E. Protter]

Shalom,

setting SHLIB_PATH is pretty standard and should be done prior to any compile or make.

Perhaps your system has a default SHLIB_PATH set in /etc/profile or the user profile.

SEP

[H.Merijn Brand (procura · Accepted solution]

Probably not.

One reason could be that HP-UX allows you to use *TWO* environment variables to set the path where shared libs are searched for, where most other systems allow only one: SHLIB_PATH and LD_LIBRARY_PATH

Each shared library in turn can enable or disable SHLIB_PATH when searching for its dependencies. Use 'chatr libfoo.sl' to check.

Last, but not least, the options used to create the library, can also include the "internal search path" or "embedded path". When that is used (see ld +b), it provides a fallback mechanism for incomplete SHLIB_PATH or LD_LIBRARY_PATH variables.

HTH, Enjoy, Have FUN! H.Merijn

[reb]

Gentlemen, thanks for you replies.

First of all, in my original post, I should have said "I need to set shlib_path AT RUN TIME to get it to work". I try to unset both LD_LIBRARY_PATH and SHLIB_PATH when I do my first compile so that I avoid receiving unknown settings from /etc/profile, etc.

The common thread seems to be libraries that have dependencies on other libraries.

For instance, lets take libgd.so (the graphics library). chatr on that shows:

libgd.so:
32-bit ELF shared library
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /usr/local/lib/hpux32
internal name:
libgd.so.2
shared library list:
/usr/local/lib/hpux32/libiconv.so
libXpm.so
libX11.so.1
/usr/local/lib/hpux32/libjpeg.so
/usr/local/lib/hpux32/libfontconfig.so
/usr/local/lib/hpux32/libfreetype.so
/usr/local/lib/hpux32/libpng12.so
libz.so
libm.so.1
libc.so.1
shared library mapped private disabled

So - here you can see that it already has /usr/local/lib/hpux32 in its embedded path. But yet, I still am required to set and export SHLIB_PATH=/usr/local/lib/hpux32 if I run a perl program that does "use GD;". That seems wrong to me. Unless perl is somehow supressing the search of the embedded path in libgd.so when trying to find libz.so.

Also, I wonder why some of these libraries have the full path listed, while libz.so does not? Sorry if these are stupid questions, I just want to understand it so I can do "the right thing" next time.

[reb]

By the way, my libgd.so came from the porting archive, so maybe they compiled it "Funny" for some reason. Also, this library installs directly into /usr/local/lib for some reason (why doesn't it go into hpux32?)...

[Dennis Handly]

For IPF, you should really use LD_LIBRARY_PATH and be industry standard.

In addition to the comments H.Merijn made, you can also link with +nodefaultrpath to ignore all of the -L paths.

>The common thread seems to be libraries that have dependencies on other libraries.

Are you talking about your perl modules, they would have to have dependencies to have -L.

>here you can see that it already has /usr/local/lib/hpux32 in its embedded path. But yet, I still am required to set and export SHLIB_PATH=/usr/local/lib/hpux32

It does seem strange. I'm not sure if there are options to dlopen or to perl itself that would do that.

>I wonder why some of these libraries have the full path listed

These libs were linked "wrong". They were linked as absolute shlib paths, rather than with -L and -ljpeg. You can fix them with:
chatr -l library file
(But I can't seem to get that to work, unless I link with +compat. Perhaps that's the issue??)

>this library installs directly into /usr/local/lib for some reason (why doesn't it go into hpux32?)...

Right it seems like it should, especially if it refers to other libs there.

[reb]

> For IPF, you should really use LD_LIBRARY_PATH and be industry standard.

Good point! I've been doing HPUX so long, I sort of forgot that SHLIB_PATH is hp-specific.

> Are you talking about your perl modules, they would have to have dependencies to have -L.

I mean perl modules that link libraries that link other libraries. For instance, GD.so (the library for GD.pm) links libgd.so (the "C" library) which in turn links libz.so (et al). Perl has no problem finding GD.so (obviously) or libgd.so, but seems flummoxed when asked to locate libz.so. (Maybe it has something to do with the fact that libz and libgd aren't living in the same directory?)

Thanks for the reply!