The bug is filed at
https://sourceware.org/bugzilla/show_bug.cgi?id=18596, and please refer to it for a test case and some description there.
In short, Gold linker will issue a warning, when a hidden or internal symbol "matches" a reference.
According to linker rule, the linker should ignore such "match" and do not have to issue warning (this is what ld.bfd do), it might try to be helpful, but some build script will do "-Werror" and there is situation the hidden symbol false match cannot be removed from the source, say, there is hidden and override of symbols.
The final resolve of the symbol may fall into the following category,
A. It will be resolved by a legal definition (this may happen before or after)
B. It will not be resolved, but it is allowed or intended for this link
(for these two cases, I wonder if how much is it helpful)
C. It will not be resolved and lead to a link error
(linker will say "undefined symbol", but a warning like "DSO can not reference a hidden symbol" may be a bit plus here)
A simple fix is to remove the warning, while if it is actually helpful to someone, there are options like, to create an option for it, to only issue a warning when the symbol is not resolved at last, or something else.
diff --git a/gold/resolve.cc b/gold/resolve.cc
index fdae0ba..af61096 100644
--- a/gold/resolve.cc
+++ b/gold/resolve.cc
@@ -286,15 +286,6 @@ Symbol_table::resolve(Sized_symbol<size>* to,
&& (to->visibility() == elfcpp::STV_HIDDEN
|| to->visibility() == elfcpp::STV_INTERNAL))
{
- // A dynamic object cannot reference a hidden or internal symbol
- // defined in another object.
- gold_warning(_("%s symbol '%s' in %s is referenced by DSO %s"),
- (to->visibility() == elfcpp::STV_HIDDEN
- ? "hidden"
- : "internal"),
- to->demangled_name().c_str(),
- to->object()->name().c_str(),
- object->name().c_str());
return;
}
else