[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.
pgpuixKVnfh4r.pgp
Description: OpenPGP digital signature