GNU bug report logs - #43591
[PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir.

Previous Next

Package: guix-patches;

Reported by: Danny Milosavljevic <dannym <at> scratchpost.org>

Date: Thu, 24 Sep 2020 14:13:02 UTC

Severity: normal

Tags: patch

Full log


View this message in rfc822 format

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43591 <at> debbugs.gnu.org, Marius Bakke <marius <at> gnu.org>
Subject: [bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir.
Date: Tue, 6 Oct 2020 17:39:32 +0200
[Message part 1 (text/plain, inline)]
Hi Ludo,

On Thu, 01 Oct 2020 09:14:10 +0200
Ludovic Courtès <ludo <at> gnu.org> 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.
[Message part 2 (application/pgp-signature, inline)]

This bug report was last modified 4 years and 250 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.