On Tue, 7 Oct 2014, Stefan Liebler wrote:
Hi,
i have tested this patch on s390.
Before this patch, the symbol lchown@@GLIBC_2.0 was weak. Now it is global.
Changing the corresponding line in syscalls.list to
"lchown - lchown32 i:sii __lchown lchown chown@GLIBC_2.0"
leads to the weak symbol.
That syscalls.list line you give won't work (with the current
make-syscalls.sh) because if any symbol versions are given, the symbol is
treated as shared-only unless some @@ version is given. That is, it would
result in lchown being missing from the static libc.
You don't say if you see any ABI test failures, or just a change in a
symbol from weak to non-weak. As long as there aren't any ABI test
failures, I don't believe the change in question is a problem.
The reason names such as lchown need to be weak aliases is for the
following combination of circumstances:
(a) a program uses only interfaces in a standard that does not include
lchown;
(b) that program defines its own symbol called lchown, which may have no
relation to glibc's;
(c) one of the glibc interfaces the program uses is implemented in a way
that uses __lchown internally;
(d) the lchown alias to __lchown now conflicts with the program's own
definition of lchown.
But this is generally only a problem for static linking. And for
non-SHARED, versioned_symbol is defined to weak_alias, so you should find
that lchown in static libc.a is still a weak symbol after my patch. In
shared libc, it shouldn't matter whether lchown is strong or weak; either
way, it won't conflict with a symbol called lchown in the user's program
and calls to __lchown from within libc will go to the right place.
In shared libc, it should only matter whether a symbol is weak if it's one
of a limited number of symbols the user's program is actually allowed to
override with the intention that the user's version of the symbol gets
used in libc - for the vast bulk of libc symbols, the rule is that if the
user defines their own symbol with that name, then behavior is undefined
if the user also uses any libc symbol from a standard containing the
symbol they defined, and otherwise the two definitions won't interfere.