Hi Ludo, On Thu, 01 Oct 2020 09:14:10 +0200 Ludovic Courtès wrote: > Could you propose a patch for maintenance.git? OK--patch #43829. > >> I have mixed feelings: fixing packages one by one doesn’t sound great, > >> but OTOH setting the ‘CFLAGS’ environment variable globally can have > >> unexpected side effects in some cases (overriding package-specific > >> CFLAGS) Doing (setenv CFLAGS "-g -O2 -D_FILE_OFFSET_BITS=64") right after phase 'set-SOURCE-DATE-EPOCH doesn't override package-specific CFLAGS. Quite the opposite can happen, though. But: > > The latter is easy to detect since I patched dirent.h in glibc exactly for that > > reason. That way, glibc WON'T let you use it wrong (except if you explicitly > > ask for it). On Guix systems, there is no legitimate reason to use it wrong > > in the first place. > > I’m very reluctant to patching public libc headers. Also, it’s not just > “our” problem, we should definitely discuss it with upstream and perhaps > propose your dirent.h patch. I've reported it upstream. However, GNU gcc and glibc support a lot of weird architectures--but Guix system really doesn't. So it's much easier for us to get a good patch than it is for them. > A diff at one point in time (if we ever managed to get a usable diff) is > not enough: problems could pop up anytime. Setting ‘CFLAGS’ globally as > an environment variable seems risky. We are about 15 years late--so all other distributions already triggered most of the bugs in that time. I don't think it's that bad anymore... That's why I would prefer setting CFLAGS globally anyway. And I don't have the energy to manually FIND AND fix however many packages are affected otherwise. Having this problem in 2020 is ridiculous--it's like someone accidentially enabled a time machine... The only reason this didn't fall on our head on x86_64 is because on 64 bit systems something like it is the default anyway.