libthr does not obey WITHOUT_SYSCALL_COMPAT

[David Xu]

Daniel Eischen wrote:
> On Mon, 9 Mar 2009, David Xu wrote:
> 
>> Daniel Eischen wrote:
>>> On Mon, 9 Mar 2009, David Xu wrote:
>>>
>>>> Pawel Worach wrote:
>>>>> Hi,
>>>>>
>>>>> If libc is built using WITHOUT_SYSCALL_COMPAT applications linked with
>>>>> libthr end up having unresolved symbols since libthr references
>>>>> __fcntl_compat unconditionally.
>>>>> Here is a patch to make libthr also obey WITHOUT_SYSCALL_COMPAT
>>>>> http://www.vlakno.cz/~pwo/libthr.diff
>>>>>
>>>>> Regards
>>>>
>>>> Committed!
>>>
>>> I never got around to replying to this...
>>>
>>> I don't quite understand why __fcntl_compat is there.  We have
>>> F_GETFD, F_SETFD, F_DUPFD, F_DUP2FD, F_GETFL, F_SETFL, F_GETOWN,
>>> and F_SETOWN according to fcntl(2).  But thr_syscalls.c only
>>> handles F_DUPFD, F_SETFD, F_SETFL, F_GETFD, and F_GETFL, leaving
>>> F_DUP2FD, F_GETOWN, and F_SETOWN to be handled by the default
>>> case.  And the default case does nothing now if WITHOUT_SYSCALL_COMPAT
>>> is defined.  So how do F_DUP2FD, F_GETOWN, and F_SETOWN get
>>> handled?
>>>
>>> Do we really need to call __sys_fcntl_compat() from libthr?
>>> When did the ABI change, before or after libc.so.7?
>>>
>>
>> I don't know when it appeared. Would this patch eliminate the shit ?
> 
> I think so.  But I think for future ABI changes to cancellation
> points, wouldn't we need syscall wrappers in libc?  Reason, libc
> and libthr are now symbol-versioned, so there will no longer be
> library bumps for ABI changes.  But if a syscall is a cancellation
> point and libthr has to play games with it, like fcntl, I think
> there should be a wrapper around it in libc.  If the ABI changes,
> then both libc and libthr would need to provide a compat version
> for it.  I think.  ;-)
> 

Yes, it is better to use versioning instead, I don't know why 
fcntl_compat is there without using this feature.