guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a


From: Danny Milosavljevic
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

Hi Ludo,

On Thu, 01 Oct 2020 09:14:10 +0200
Ludovic Courtès <ludo@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.

Attachment: pgpuixKVnfh4r.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]