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

[Ian Lance Taylor <ian at airs dot com>]

"H. J. Lu" <hjl@lucon.org> writes:

> On Tue, Aug 12, 2003 at 09:44:28AM -0700, Ian Lance Taylor wrote:
> > David Wuertele <dave-gnus@bfnet.com> writes:
> > 
> > > I want to create a dynamic library, libA, that links with libB.  Then
> > > I want to create an executable that links with libA.  But I don't want
> > > to have to have libB around at compile time.  But gcc/ld complains if
> > > libB.so is not there!  Why is that?  My executable only makes calls to
> > > libA.  The dynamic loader should take care of libB, not the linker!
> > > 
> > > In windows, you can do what I want.  I've constructed two scripts, one
> > > for Linux using gcc/ld, and one for windows using cl/link, to
> > > demonstrate what I want to do and what is going wrong in Linux.  Can
> > > anyone tell me how to achieve this with gcc/ld?
> > 
> > I think this is a bug.  The GNU linker is reporting an error where it
> > should report a warning.
> > 
> > Any comments on this patch?
> > 
> 
> I prefer something like this.
> 
> 
> H.J.
> ----
> --- bfd/elflink.h.undef	2003-08-07 09:04:31.000000000 -0700
> +++ bfd/elflink.h	2003-08-12 10:38:32.000000000 -0700
> @@ -4380,7 +4380,7 @@ elf_link_output_extsym (struct elf_link_
>      {
>        if (! ((*finfo->info->callbacks->undefined_symbol)
>  	     (finfo->info, h->root.root.string, h->root.u.undef.abfd,
> -	      NULL, 0, TRUE)))
> +	      NULL, 0, ! finfo->info->allow_shlib_undefined)))
>  	{
>  	  eoinfo->failed = TRUE;
>  	  return FALSE;

I may be confused on the meaning of the --allow-shlib-undefined
option.  The documentation is a bit confusing.  If I read it
carefully, it appears to mean that if --allow-shlib-undefined is set,
then it is OK to link against a shared library which has undefined
references which are not satisfied by anything else in the link.

However, that does not match the code.  For example, in the very place
we are looking at, elf_link_output_extsym(), we see this:
      && (finfo->info->executable
	  || ! finfo->info->allow_shlib_undefined)
That clearly suggests that the --allow-shlib-undefined option refers
not to the case of linking against a shared library, but to the case
of creating a shared library.

This code was inserted with this patch:

2003-02-17  Nick Clifton  <nickc@redhat.com>

	* elflink.h (elf_link_output_extsym): Only check
	allow_shlib_undefined for shared libraries.

So before deciding on that patch, I need to understand what
--allow-shlib-undefined is supposed to mean.

To be as clear as I can, there are two possibilities:

1) When linking against shared library A to form an executable or
   shared library B, if A has any undefined references which are not
   satisfied by anything else in the link, that is OK.

2) When creating a shared library A, if A has any undefined references
   which are not satisfied by anything else in the link, that is OK.

The documentation is hard for me to understand, but suggests
alternative 1.  The code in elf_link_output_extsym() appears to
implement alternative 2.

If alternative 1 is correct, then I agree with your patch.  And I
think that the immediately preceding condition in
elf_link_output_extsym() should not refer to allow_shlib_undefined.

Note that the allow_shlib_undefined field was introduced with this
ChangeLog entry in the bfd directory:

2000-12-10  Fred Fish  <fnf@be.com>

	* elflink.h (elf_link_output_extsym): Don't complain about undefined
	symbols in shared objects if allow_shlib_undefined is true.

This too is ambiguous, but suggests that if --allow-shlib-undefined is
set, the code should not even issue a warning.

Ian