Re: How do I link to a shared lib without having that lib's dependencies (the way MS link does)

["Don Woodward" <woodward at woodward dot org>]

Thanks Ian, for the reply.

I think I understand what the linker is trying to tell me:

Basically when I say -lB, at load time the loader is doing the equivalent
of:
dlopen("libB.so", RTLD_LAZY);
which in turn does a
dlopen("libC.so", RTLD_LAZY);

Since, libB and libC are loaded with lazy binding,
as prog is executed, a function call in libB which calls an undefined symbol
in libC will result in prog crashing.

This is why the linker is requiring prog to also link against libC, so that
it
can check the symbols and give me an error (proposed patch changes this
to a warning) if not all of libC's symbols that prog uses indirectly through
libB can be resolved.

I propose that this is a bogus check.  I understand the intent of the check,
but one of the neat features of shared libraries is that I can keep my
interface
to the library the same, change the implementation, and clients of my
library
won't have to recompile.  Imagine I change libB so that it no longer depends
on libC, and release a new libB.so.  I think that is a perfectly valid and
legal
thing to do.  Now my clients that have previously
linked against libB and libC (libC just for the purposes of the linker being
friendly), have had that friendly symbol checking rendered obsolete.
So, why do it in the first place?  Because the linker is being friendly and
trying
to warn me that my program might crash in the future.

Which begs the following question: is there a linker option where I can
build
my shared libraries and programs so that the loader invokes all dlopens
with RTLD_NOW?  I think lazy binding is a neat feature, but I'd like to
choose RTLD_NOW if I want so that the loader will refuse to run
my client's programs if there are symbol problems with my shared library
chain that they are trying to use.  If I could do a link option that forces
the loader to load with RTLD_NOW, then the behavior would be the
same as on Windows, which, as you pointed out, is that the program
is refused to be run if either libC doesn't exist, or libB can't get all of
libC's symbols at load time.

Basically, what I'm after is the ability to modify the implementation of
libB at will without affecting my clients or requiring them to recompile
(which brings up a ton more issues related to how I structure my libraries
which I haven't fully figured out yet).  Did I mention that I hate COM?

-Don