unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Marius Bakke <marius@gnu.org>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: 43591@debbugs.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: Fri, 25 Sep 2020 01:11:18 +0200	[thread overview]
Message-ID: <87tuvm4vop.fsf@gnu.org> (raw)
In-Reply-To: <20200924222711.2f22281a@scratchpost.org>

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> 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).

Why is this not an issue with i686 on x86_64 kernels?  Or armhf on
AArch64?  This problem only manifests when using QEMUs syscall
emulation, right?

> 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.

Arguably running code for foreign architectures through QEMU binfmt is
something of a hack.  Mandating that every package *must* be patched to
support it seems user-hostile.  I'm more in favor of dropping it on the
build farm, or just keep fixing things on a per-package basis.

A less user-hostile solution could perhaps be to (setenv "CFLAGS"
"-D_FILE_OFFSET_BITS=64") on 32-bit architectures in gnu-build-system.
Not sure whether that could cause any adverse effects.  But again, I
don't like the idea of optimizing for QEMUs user-mode emulation.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2020-09-24 23:12 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 14:12 [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
2020-09-24 14:16 ` Danny Milosavljevic
2020-09-24 18:17 ` Marius Bakke
2020-09-24 20:27   ` Danny Milosavljevic
2020-09-24 23:11     ` Marius Bakke [this message]
2020-09-25 10:20       ` Danny Milosavljevic
2020-09-25 10:42         ` [bug#43591] [PATCH v2 core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir regardless Danny Milosavljevic
2020-09-25 13:36         ` [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
2020-09-25 15:33           ` Danny Milosavljevic
2020-09-26  1:42           ` Danny Milosavljevic
2020-09-26  1:49             ` Danny Milosavljevic
2020-09-29 14:51               ` Danny Milosavljevic
2020-09-27  6:43           ` Efraim Flashner
2020-09-25 20:03       ` Andreas Enge
2020-09-26 10:50         ` Danny Milosavljevic
2020-09-29 20:52       ` Ludovic Courtès
2020-09-29 22:09         ` Danny Milosavljevic
2020-09-30  9:32           ` Ludovic Courtès
2020-09-30 10:28             ` Danny Milosavljevic
2020-10-01  7:14               ` Ludovic Courtès
2020-10-02  7:18                 ` Danny Milosavljevic
2020-10-02  8:12                   ` Danny Milosavljevic
2020-10-02  9:47                     ` Danny Milosavljevic
2020-10-02  9:32                   ` Danny Milosavljevic
2020-10-06 15:39                 ` Danny Milosavljevic
2020-09-25 10:24   ` Danny Milosavljevic
2020-09-30  8:45 ` [bug#43591] [PATCH core-updates v2 0/5] " Danny Milosavljevic
2020-09-30  8:45   ` [bug#43591] [PATCH core-updates v2 1/5] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir regardless Danny Milosavljevic
2020-09-30 16:55     ` Danny Milosavljevic
2020-09-30  8:45   ` [bug#43591] [PATCH core-updates v2 2/5] build-system/gnu: Explicity declare the _FILE_OFFSET_BITS we want Danny Milosavljevic
2020-09-30  8:45   ` [bug#43591] [PATCH core-updates v2 3/5] gnu: glibc: Do not explicitly set _FILE_OFFSET_BITS Danny Milosavljevic
2020-09-30  8:45   ` [bug#43591] [PATCH core-updates v2 4/5] gnu: glibc-mesboot0: " Danny Milosavljevic
2020-09-30  8:45   ` [bug#43591] [PATCH core-updates v2 5/5] gnu: rhash: Explicity declare the _FILE_OFFSET_BITS we want Danny Milosavljevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tuvm4vop.fsf@gnu.org \
    --to=marius@gnu.org \
    --cc=43591@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).