[PATCH 2/3] msqid: Provide internal copy of struct __msqid64_ds

[Adhemerval Zanella]

On 13/11/2020 11:42, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> On 12/11/2020 19:02, Lukasz Majewski wrote:
>>> Those issues are not resolved since 2012, so I do guess that those
>>> are not very urgent or easily solvable.
>>>
>>> The Y2038 support will have consistent name scheme for functions
>>> aliased (e.g. foo) to 64 bit versions (__foo64 or __foo_time64). If
>>> we can get away with having the latter exported, so they will not
>>> clash, it shall be Ok.   
>>
>> I would guess there are not easily solvable, so I would expect that
>> the default _TIME_BITS for 32-bit architecture with legacy 32-bit
>> time_t support would still be '32'. 
> 
> No,  in this case we would use the names without any suffix - e.g.
> clock_gettime instead of __clock_gettime64.

The linkage name is already handle by the __REDIRECT (if compiler supports
is) macro, which creates a linkage alias.  The code will call 
clock_gettime, but static linking will bind to __clock_gettime64.

> 
>> This unfortunately would require
>> to be explicit enable on the projects build system and it might not
>> straightforwards to enable worldwide since we got reports that recent
>> debian builds still do not enable LFS support on all packages.
> 
> I think that it will not be so problematic in the end of the day. When
> we set default minimal supported kernel version to 5.1+, the _TIME_BITS
> = 64 can be enabled by default (on ports with __WORDSIZE=32 &&
> __TIMESIZE != 64). Until then users would be allowed to pass it with
> -D/Makefile.

I don't think this is that simple for 32-bit ports with 32-bit time_t,
no without fixing or discussing the LFS bug reports.  For
_FILE_OFFSET_BITS=64 I think the solution outline by Rich on comment#2
from BZ#14106 should be suffice (rename all the *64 functions to __*64
and update the headers accordingly), we will still need to keep exporting
the symbols for both compatibility and _LARGEFILE64_SOURCE.

> 
>>
>> I do think we should eventually enable both LFS and 64-bit time as
>> default for *all* architectures; this solves a lot of possible
>> issues.
> 
> Yes. I do agree.
> 
>>
>>>>
>>>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=14106
>>>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=15766 
>>>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=13047  
>>
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20201113/f00b35b3/attachment.sig>