How do I link to a shared lib without having that lib's dependencies (the way MS link does)
H. J. Lu
hjl@lucon.org
Tue Aug 12 18:35:00 GMT 2003
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.
More information about the Binutils
mailing list