* Richard W. M. Jones via Libc-alpha:
> On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote:
>> On 2023-03-02 01:04, Daniel P. Berrangé wrote:
>> >IMHO if distros really want to deal with this, they need to be able to
>> >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.
>>
>> As things stand this is probably the best way to go. Although some
>> pain is inevitable, this approach appears to be the least painful.
>
> I think the question remains how to do this. In Fedora we have a
> concept of global C/C++ flags which most C/C++ applications obey:
>
> $ rpm --eval '%{__global_cflags}'
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>
> We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.
> We didn't historically do this for -D_FILE_OFFSET_BITS, instead
> relying on every application to switch for itself.
That still needs some per-package work (mainly for scripting languages
using FFI) because dlsym for gettimeofday etc. still find the 32-bit
variant. There are various ways we can hack around that, I guess.
Anyway, this dual ABI break (for off_t and time_t) needs to be proposed
as a Fedora change, and we can discuss mechanics if Fedora wants to move
in that direction. I think this is far from a given because a
still-unknown amount of third-party software will break. GNUTLS, for
example, used to have a fairly stable ABI: libgnutls.so.30 goes back a
couple of years; I think it was part of CentOS 7 already.
I think the first step is to decide if we want to do this. After that,
we can discuss mechanics. For example, traditionally, ABI changes like
this have not been implemented through build flags injection in Fedora,
rather we updated the toolchain defaults.
Needless to say, I have very little interest to work on this (I consider
all this a pointless distraction, to be blunt), but I guess I can help
with toolchain enablement.
Thanks,
Florian
