[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On time64 and Large File Support
From: |
Bruno Haible |
Subject: |
Re: On time64 and Large File Support |
Date: |
Thu, 02 Mar 2023 13:17:33 +0100 |
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++, glib-2.0, gtk+-3.0, libpng, nettle, openssl,
readline, libuuid, wxwidgets, X11, libxcb
- and that's just the few that I happen to have installed.
If a distro takes a package-by-package approach:
- Some of these packages use Gnulib, and are thus causing trouble now or
will soon.
- The other packages (and there are a number of them!) will either
require a manual switch to _TIME_BITS=64 or blow up in 2038.
I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass
rebuild is
- more efficient than a package-by-package approach,
- also less likely to leave out some packages by mistake.
> 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.
How do you detect if a package (by mistake or intentionally) does
'#undef _TIME_BITS'?
A safer solution might be to hack the compilers (gcc and clang), so that
they make _TIME_BITS evaluate to 64, regardless of any '#define _TIME_BITS 32'
or '#undef _TIME_BITS' in the package's source code.
Bruno
- Re: On time64 and Large File Support, Eric Blake, 2023/03/01
- Re: On time64 and Large File Support, Demi Marie Obenour, 2023/03/01
- Re: On time64 and Large File Support, Daniel P . Berrangé, 2023/03/02
- Re: On time64 and Large File Support, Paul Eggert, 2023/03/02
- Re: On time64 and Large File Support, Richard W.M. Jones, 2023/03/02
- Re: On time64 and Large File Support,
Bruno Haible <=
- Re: On time64 and Large File Support, Daniel P . Berrangé, 2023/03/02
- Re: On time64 and Large File Support, Wookey, 2023/03/02
- Re: On time64 and Large File Support, Paul Eggert, 2023/03/03
- Re: On time64 and Large File Support, Wookey, 2023/03/03
- Re: On time64 and Large File Support, Daniel P . Berrangé, 2023/03/03
- Re: On time64 and Large File Support, Arsen Arsenović, 2023/03/04
- Re: On time64 and Large File Support, Florian Weimer, 2023/03/03
- Re: On time64 and Large File Support, Richard W.M. Jones, 2023/03/03
- Re: On time64 and Large File Support, Andreas Schwab, 2023/03/02
- Re: On time64 and Large File Support, Paul Eggert, 2023/03/03