qazmlp wrote:
> I have a shared library libFirst.so
> I have a shared library libSecond.so which has dependency libFirst.so.
> Hence, while producing the libSecond.so, I have to add the path to
> libFirst.so
> in the LD_LIBRARY_PATH
>
> I have a shared library libThird.so which has dependency only on
> libSecond.so.
> So, I mentioned the path to only libSecond.so in the LD_LIBRARY_PATH
> while producing
> libThird.so.
> But, the linker reports error pointing at the symbols in libFirst.so
> After adding the path to libFirst.so also in the LD_LIBRARY_PATH, the
> error disappears.
>
> I am wondering why such a requirement of adding the path of some other
> shared libraries also is required when my library libThird.so does not
> have a direct dependency on them.
>
> Kindly clarify!

The default linker behavior when linking a program or .so is to fully
resolve all symbols including the dependencies in .so's indirectly
referenced.

Don't rely on LD_LIBRARY_PATH to resolve link time references.  Specify
the library locations on the compiler (or linker) command line (e.g.
-L<path to non-system-standard-libraries> ).

-- ced


--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

[ Post a follow-up to this message ]

qazmlp wrote:
> Chuck Dillon <cdillon@nimblegen.com> wrote in message news:<c3s731$1tc$1@g
randcanyon.binc.net>...
> 
>
> If default behaviour is so, is it possible to change such that, we do
> not to give the path for indirect dependencies?
>

(Solaris specific info...)
I was incorrect in saying the default behavior for linking shared
objects is to choke on unresolved symbols.  The default behavior of ld
is to allow them.  The -z defs switch of ld (see man ld) forces
resolution of all symbols.

I suggest you reference the man pages for your compiler, ld and look at
the "libraries and linkers guide" at docs.sun.com.

-- ced

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

[ Post a follow-up to this message ]