Re: On time64 and Large File Support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 03, 2023 at 12:49:04PM +0100, Florian Weimer wrote:
> * 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.

To be clear, I wasn't suggesting we should do this, merely that it's a
thing that could be done :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux