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
