Incorrect embedded library names in shared library

[Jim Gallagher]

Hi,

While building a shared library, I noticed that if I pass a path to a dependent shared library on the link line (as opposed to using the -l and -L linker options), the path is embedded in the new library. For example, building libbar that depends on libfoo:

$ aCC -AA -b +DD64 -g -mt -o libbar.so bar.o ../foo/bin/libfoo.so

results in:
$ chatr libbar.so
libbar.so:
64-bit ELF shared library
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /usr/lib/hpux64:/opt/langtools/lib/hpux64
shared library list:
../foo/bin/libfoo.so
libpthread.so.1
.
.
.

The name of libfoo.so is embedded with the path used on the link line. Now libbar will only load if the relative path to libfoo.so resolves- LD_LIBRARY_PATH and SHLIB_PATH do not work. Is this the way it should work? I would think that just the name of the library should be embedded.

Thanks,
Jim Gallagher

[James R. Ferguson · Accepted solution]

Hi Jim:

See:

http://docs.hp.com/en/9482/linkertasks.htm#notrecordinglinktime

Regards!

...JRF...

[Jim Gallagher]

JRF,

That was a very fast reply, thank you.

I ran into this using Boost-Build to run the the build of a several library project. Do you know if this behavior is similar on other Unix variants?

Thanks,
Jim

[Dennis Handly]

If not clear from JRF's link you should be using -L and -l:
-L../foo/bin -lfoo

(You should also be putting foo in a lib/ directory, not bin/.)

[Jim Gallagher]

ok