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

[Danny Milosavljevic]

Hi Marius,

On Thu, 24 Sep 2020 20:17:14 +0200
Marius Bakke <marius@gnu.org> wrote:

> As mentioned in that issue, and which this patch states on no uncertain
> terms, a workaround is to use -D_FILE_OFFSET_BITS=64 on 32-bit platforms.

Yeah.  The problem is how to find all those places where we need to add it,
and how to keep finding them as we maintain stuff (read: as upstream changes
stuff).

> Won't this break _everything_ that uses readdir() without 64-bit
> offsets?

That's the goal of that patch.  Because it won't work at runtime anyway, when
run on a guix x86_64 build machine, building for ARM (which is the usual way
we build stuff for ARM).

Maybe we can find out whether dirent.h is #included for compiling for one of
the main Guix platforms (I prefer this latter solution, if possible).

It's either that or we stop qemu transparent emulation on the build farm,
because the result isn't reliable.  This time it was "caught" because of
an overabundance of caution on behalf of the glibc people.  We won't be
so lucky next time.

>  Or does that @@ string get substituted by the glibc build
> system somehow.

No.  It's specifically made so downstream users of glibc on guix can't use
readdir() on 32-bit systems without enabling large file support.

It totally could use some more #if about whether it's building stuff for
an actual guix main platform (i.e. not on embedded).

> Can you file a bug report upstream about the duplicate definition(s)?

It's not really a problem for them.  But I can try anyway.

> Enforcing this restriction in glibc feels rather sledgehammer-y.  Would
> it make sense to introduce a GCC warning instead?  I'm sure there are
> legitimate uses of smaller file offsets (i.e. embedded).  A GCC warning
> will still break -Werror, but that's a lot more manageable than breaking
> almost every use of readdir() on 32-bit platforms.

I thought about a gcc #warning.  But I don't want it to warn when readdir
isn't used in the first place but dirent.h ended up being included by some
dependency.  I guess we could use a deprecation warning on readdir() instead.
Can this warning print a custom message?

What do you think?

In any case, I'd like to have some overview of how bad the problem is and
thus I'd like to have a wip branch with this patch being built entirely
for 32 bits via x86_64 (not sure whether that includes i686 btw).
Is it possible to force using these x86_64 machines in the build farm?

>I'm sure there are legitimate uses of smaller file offsets (i.e. embedded).

On guix?  With our glibc?  Do we support that?

>A GCC warning will still break -Werror, but that's a lot more manageable
>than breaking almost every use of readdir() on 32-bit platforms.

These uses of readdir() are not reliable the way we are building guix on
cuirass.

But I'm all for refining this patch, if there are suggestions on how.

Actually, I think a warning is not strong enough.  This bug made it all the
way down to json-c (!) before finally being detected.  That should not happen.

And if the build farm would have selected an actual ARM machine, the build
would have succeeded and no one on x86_64 could have reproduced the result.
That would have been real bad.

pgpmXv448JlB4.pgp
Description: OpenPGP digital signature