This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |