On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote: > On 2022-09-28 09:32 -0400, Jeffrey Walton wrote: >> On Wed, Sep 28, 2022 at 3:24 AM Dominique MARTINET >> <dominique.marti...@atmark-techno.com> wrote: >> > ... >> > Ugh, this is going to be a massive headache... >> > Other distributions I've worked with (e.g. nixos) have a wrapper for gcc >> > and clang that just enforce the flags they want the distro to be built >> > with -- I don't think debian has anything like that, would that be >> > easier to work with? My line of thinking is that there will only be a >> > single place to fix instead of configure/cmake/meson and all hand-made >> > build scripts that exist around here. >> >> Debian has dpkg-buildflags . Discussions about it show up when >> discussing hardening, like [0]. >> >> [0] https://wiki.debian.org/Hardening#dpkg-buildflags > > Right, and just changing it and rebuilding works very well. I did this > for PAC (pointer authentication) support last year. Very few packages > do not correctly honour dpkg-buildflags. > > In fact the only issue was that I unconditionally changed it so it got > issued by some packages (like migw) for the wrong-arch compiler > (because they were cross-building). One should be a bit smarter to > unconditionally set an _arch-specific_ flag.
I think the problem with using dpkg-buildflags is that it breaks any user building their own applications against Debian provided libraries, unless they remember to set the flag manually. > dpkg-buildflags has functionality for this. See patch at bottom of: > https://lists.debian.org/debian-dpkg/2022/05/msg00022.html > > Presumably the 'use 64-bit time_t' flag is the same for all arches, > but may only exist on 32-bit arches? Yes. The flag is -D_TIME_BITS=64, and this can be set unconditionally everywhere if that helps. Note that this implies -D_FILE_OFFSET_BITS=64, i.e. you can't have 64-bit time_t without 64-bit off_t/ino_t/... As far as I understand, there are still a few libraries in Debian that are built with 32-bit off_t in order to not break the traditional ABI, and that is fine because off_t is rarely used in non-libc header files, and a lot of applications don't actually need to understand large file sizes (e.g. when they call 'fstat()' to get the file timestamp but not the size, or when they operate on files that are otherwise limited to less than 4GB). So with time64, there will be an ABI change both for the few libraries that are currently using 32-bit off_t in addition to those that use time_t/timeval/timespec, and the original problem with off_t is amplified because there are many more libraries that have ABIs based around time_t. This is also going to be hard for non-C languages with C bindings (python, rust, ...) that have structure types hardcoded. Arnd
