mirror of git://sourceware.org/git/glibc.git
db7dbeed8d
Clang issues a warning for double alias redirection, indicating that thei
original symbol is used even if a weak definition attempts to override it.
For instance, in the construction:
int __internal_impl (...) {}
weak_alias (__internal_impl, external_impl);
#if SOMETHING
weak_alias (external_impl, another_external_impl)
#endif
Clang warns that another_external_impl always resolves to __internal_impl,
even if external_impl is a weak reference. Using the internal symbol for
both aliases resolves this warning.
This issue also occurs with certain libc_hidden_def usage:
int __internal_impl (...) {}
weak_alias (__internal_impl, __internal_alias)
libc_hidden_weak (__internal_alias)
In this case, using a strong_alias is sufficient to avoid the warning
(since the alias is internal, there is no need to use a weak alias).
However, for the constructions like:
int __internal_impl (...) {}
weak_alias (__internal_impl, __internal_alias)
libc_hidden_def (__internal_alias)
weak_alias (__internal_impl, external_alias)
libc_hidden_def (external_alias)
Clang warns that the internal external_alias will always resolve to
__GI___internal_impl eve if a weak definition to __GI_internal_impl is
overriden. For this case, a new macro named static_weak_alias is used
to create a strong alias for SHARED, or a weak_alias otherwise.
With these changes, there is no need to check and enable the
-Wno-ignored-attributes suppression when using clang.
|
||
|---|---|---|
| .. | ||
| bits/types | ||
| sys | ||
| Makefile | ||
| Versions | ||
| bug-ulimit1.c | ||
| getpriority.c | ||
| getrlimit.c | ||
| getrlimit64.c | ||
| getrusage.c | ||
| nice.c | ||
| setpriority.c | ||
| setrlimit.c | ||
| setrlimit64.c | ||
| tst-getrlimit.c | ||
| ulimit.c | ||
| ulimit.h | ||
| vlimit.c | ||
| vtimes.c | ||