[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/15478] -no-as-needed required to avoid runtime symbol lookup e

From: ccoutant at google dot com
Subject: [Bug gold/15478] -no-as-needed required to avoid runtime symbol lookup error
Date: Mon, 20 May 2013 21:43:58 +0000


--- Comment #11 from Cary Coutant <ccoutant at google dot com> 2013-05-20 
21:43:58 UTC ---
> diff --git a/gold/symtab.cc b/gold/symtab.cc
> index 2e17529..595df56 100644
> --- a/gold/symtab.cc
> +++ b/gold/symtab.cc
> @@ -2381,7 +2381,17 @@ Symbol_table::set_dynsym_indexes(unsigned int index,
>        // and without a version.
>        if (!sym->should_add_dynsym_entry(this))
> -       sym->set_dynsym_index(-1U);
> +       {
> +         sym->set_dynsym_index(-1U);
> +         // If the symbol is defined in a dynamic object and is
> +         // referenced strongly in a dynamic object, then mark the
> +         // dynamic object as needed.  This is used to implement
> +         // --as-needed.  This is for compatibility with the GNU
> +         // linker.
> +         if (sym->is_from_dynobj()
> +             && !sym->is_undef_binding_weak())
> +           sym->object()->set_is_needed();
> +       }
>        else if (!sym->has_dynsym_index())
>         {
>           sym->set_dynsym_index(index);
> I've added a test case for this, too. Ian, if you think this is
> reasonable, I'll go ahead and commit it.

Still not quite there. This patch breaks --as-needed completely,
always marking every shared library as needed.

The more I try to make this work and think about the complications,
the more I think gold is already doing it right. Gold doesn't
currently track whether a symbol defined in a shared object is
referenced by a different shared object. Even if it did, we'd have to
keep track of all such references and do a transitive closure on each
reference to make sure that the reference comes from a "needed"
library before marking the new library as "needed". I'm now retreating
to my earlier position that this is not something we want gold to
support. We should be encouraging proper program structure where each
load module declares its direct dependencies, and only its direct

I guess that means we should document somewhere what the difference is
between Gnu ld and gold. I don't think changing the name of the option
is right, because it's a subtle difference that arguably affects only
programs whose dependencies are already improperly recorded. But since
Gnu ld does explicitly cover this particular case, we should probably
say something. We don't have a gold manual, nor do we have a document
that lists the differences between Gnu ld and gold -- we should have
at least one of those, but until we do, should we just edit the help
text? I'm not sure how to describe this difference in an economical
way that will fit in the help text.


Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]