Re: On time64 and Large File Support

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