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:35:14AM -0700, H. J. Lu wrote:
> 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.
> 

This is what I meant.


H.J.

Attachment: binutils-undef.patch
Description: Text document