[v2] Move some chown / lchown / fchown definitions to syscalls.list (bug 14138)

[Stefan Liebler]

Hi Joseph,

there are no ABI test failures on s390/s390x. There is the mentioned 
change from weak to non-weak in libc.so. In libc.a the lchown symbol is 
weak as you said.

Thanks.
Bye

On 10/07/2014 06:38 PM, Joseph S. Myers wrote:
> 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.
>