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

[H. J. Lu]

On Mon, Apr 25, 2005 at 06:10:48PM -0700, David Wuertele wrote:
> HJL> If you want to give your users a libA.so, which isn't fully
> HJL> functional at link-time, why not give them a dummy libA.so with
> HJL> the same ABI for link-time only? I assume your run-time
> HJL> environment is different from link-time. Of course, they can't
> HJL> use the dummy libA.so for the the run-time environment.
> 
> I actually have two sets of users I want to satisfy: A) those whom you
> describe, for whom there is no libB.so on their filesystem, and B)
> those who are actually compiling natively but whom I don't want to
> teach them the entire litany of dozens of dynamic libraries that their
> programs will depend upon when all they need to know is that they
> should link against libA.so.
> 
> For the second group of users, I can't give them a dummy libA.so,
> because they need the real libA.so.
> 
> Each time I add functionality to my libA.so by porting other libraries
> that it then depends upon, I have to tell my SDK users to keep editing
> their Makefiles and recompiling their software, when in fact my libA's
> API has not changed one bit, and there is no need for them *or* their
> linkers to know at link time what dependencies libA.so has (they are
> guaranteed that libA.so's dependencies will be satisfied).
> 

One way to address is to use a soname for libA.so. You can have

1. Make the real libA.so with soname libA.so.xxx, libA-xxx.so, or
anyname you like.
2. A dummy libA.so of the same ABI with the same soname.
3. Everyone will link against the dummy libA.so.
4. The executable will use the soname of libA.so.

BTW, on Linux, libc.so looks like

bash-3.00$ cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
bash-3.00$


H.J.