Re: On time64 and Large File Support

2023-03-02 Thread Paul Eggert
On 3/2/23 19:30, Wookey wrote: Gnulib automatically changing the ABI for packages that use it is deeply unhelpful and is going to cause significant breakage and hassle. This change to Gnulib was reverted in December[1] and that propagated into bleeding-edge GnuTLS last month[2]. So if I

Re: On time64 and Large File Support

2023-03-02 Thread Paul Eggert
On 3/2/23 02:38, Andreas Schwab wrote: There is a huge difference between them: time_t has a flag day, off_t doesn't. Absolutely right. Another thing that's different is that when off_t grew in the 1990s, people said they needed a wider off_t RIGHT NOW, because programs wouldn't work on

Re: On time64 and Large File Support

2023-03-02 Thread Wookey
On 2023-03-02 13:24 +, Daniel P. Berrangé wrote: > On Thu, Mar 02, 2023 at 01:17:33PM +0100, Bruno Haible wrote: > > Richard W.M. Jones wrote: > > > Another way to look at this is that it's a bug in gnutls and we should > > > fix it only in this package > > > > It's by far not just this one

Re: On time64 and Large File Support

2023-03-02 Thread Andreas Schwab
On Mär 02 2023, Paul Eggert wrote: > Fifteen years from now we'll be saying the same thing about > _TIME_BITS. There will be some pain in the meantime, just as there was > with the _FILE_OFFSET_BITS transition, something I lived through and was > not too happy about either. There is a huge

Re: On time64 and Large File Support

2023-03-02 Thread Daniel P . Berrangé
On Thu, Mar 02, 2023 at 01:17:33PM +0100, Bruno Haible wrote: > Richard W.M. Jones wrote: > > Another way to look at this is that it's a bug in gnutls and we should > > fix it only in this package > > It's by far not just this one package. An 'fgrep -rl time_t /usr/include' > search shows a

Re: On time64 and Large File Support

2023-03-02 Thread Daniel P . Berrangé
On Wed, Mar 01, 2023 at 07:29:01PM -0500, Demi Marie Obenour wrote: > On 3/1/23 17:38, Eric Blake wrote: > > [replying to the original post, because I'm not sure where else in the > > more recent activity on this thread would be more appropriate] > > > > On Fri, Nov 11, 2022 at 08:38:18AM +,

Re: On time64 and Large File Support

2023-03-02 Thread Richard W.M. Jones
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

Re: On time64 and Large File Support

2023-03-02 Thread Richard W.M. Jones
On Wed, Mar 01, 2023 at 04:38:59PM -0600, Eric Blake wrote: > [replying to the original post, because I'm not sure where else in the > more recent activity on this thread would be more appropriate] > > On Fri, Nov 11, 2022 at 08:38:18AM +, Sam James wrote: > > Hi all, > > > > In Gentoo,

Re: On time64 and Large File Support

2023-03-02 Thread Bruno Haible
Richard W.M. Jones wrote: > Another way to look at this is that it's a bug in gnutls and we should > fix it only in this package It's by far not just this one package. An 'fgrep -rl time_t /usr/include' search shows a number of libraries that use time_t in their API: alsa, boost, libstdc++,

Re: On time64 and Large File Support

2023-03-02 Thread Paul Eggert
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