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

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Wed, 30 Sep 2020 11:32:58 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Dropping emulated builds, or at least 32-bit emulated builds.  We just
>> need to remove build machines from the file above.
>
> Oh.
>
> Do we have real armhf machines?  (as in not aarch64)
>
> *Looks at guix-maintenance*  We do.  Awesome.  Then sure.
>
> But just to be clear, WE MUST NOT USE aarch64 to build armhf as long as this
> problem isn't fixed.
>
> This problem has nothing to do with emulation.

Now I’m lost; I thought this had to do with qemu-user.

Could you propose a patch for maintenance.git?

> I want to know what actually changes in the final binaries.  Surely that works
> somehow--guix data services or not.
>
> Basically, for each package in Guix,
>
>   diff -r `~/broken-guix/pre-inst-env guix build $package` `~/fixed-guix/pre-inst-env guix build $package` || echo "affected: $package"
>
> but after replacing references by deduplicated content addressed references
> (for example if derivation A refers to files in derivation B, but derivation B
> only changed the directory name it's in and not the content of the derivation,
> then that should not count as a diff in A.  That should happen recursively).

Yeah, you “just” need to compare modulo store file names…

>> 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) and zero effects in other cases (for non-Autoconf packages or
>> badly-written ‘configure.ac’ files), both of which would be hard to
>> detect.
>
> 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’m also not sure what you mean by “using it wrong”, what is “it”?

Building without _FILE_OFFSET_BITS=64 is still a valid option, albeit
one that is not recommended.

> About the unexpected side effects--yes, that's right.  That's why we should get
> a list of diff results (see above for the command) and then manually look at
> the source code of those packages and their dependencies.

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.

>> If we take a step back: what’s the problem?
>
> It means we have no trustworthy i686 packages, which means we do not have a
> trustworthy full source bootstrap using Mes (since that uses i686 executable
> to bootstrap).
>
> In practice, this problem is not so bad since the kernel on i686 has a compat
> layer that hasn't been telling us the truth for d_off, so we should be "good".
> But philosophically, we are doing it dead wrong.
>
> Also, this won't work on armhf or any other 32 bit architecture--so there,
> we would be both philosophically and practically wrong.
>
> Also, the "not telling us the truth for d_off on i686" is a leaky compat layer.
> It totally DOES wind up telling us the truth sometimes (see my earlier test
> table)--and then we have a problem.

Hmm I guess I need to re-read all that, I’m overwhelmed.

Thanks,
Ludo’.