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

["H. J. Lu" <hjl at lucon dot org>]

On Tue, Aug 12, 2003 at 11:00:40AM -0700, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > 
> > 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.

I went over this piece of code myself a few times. It was not clear
to me either. We can always clearify it. But I don't want to make it
a warning unconditionally. Maybe we should add another option to ignore
the undefined references from shared objects when creating executables.
Or we can change the default of allow_shlib_undefined to FALSE when
creating executables.


H.J.