GNU bug report logs - #43513
readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents64

Previous Next

To reply to this bug, email your comments to 43513 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: <bug-guix <at> gnu.org>
Subject: json-c build failure (on armhf-linux) while trying to build u-boot
Date: Sat, 19 Sep 2020 17:36:28 +0200

[Message part 1 (text/plain, inline)]

Hello,

there is a build failure in json-c:

$ guix environment -s armhf-linux --pure u-boot-a20-olinuxino-micro
[...]
running 'cmake' with arguments ("../json-c-0.14" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPATH=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON")
CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)


CMake Error at /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
  list sub-command REMOVE_ITEM requires two or more arguments.
Call Stack (most recent call first):
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /gnu/store/8aamffn0azz4jx4m18pzw4k14sr437ly-cmake-minimal-3.16.5/share/cmake-3.16/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:10 (project)

-- The C compiler identification is unknown
[...]
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
Warning: doxygen not found, the 'doc' target will not be included
-- Configuring incomplete, errors occurred!
See also "/tmp/guix-build-json-c-0.14.drv-0/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/guix-build-json-c-0.14.drv-0/build/CMakeFiles/CMakeError.log".
command "cmake" "../json-c-0.14" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPATH=/gnu/store/yqaw63n8wmg7f2ncc24019z87m5cwhim-json-c-0.14/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON" failed with status 1

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /gnu/store/z8954h4nvgxwcyy2in8c1l11g199m2yb-gcc-7.5.0/bin/gcc 
Build flags: 
Id flags:  

The output was:
1
CMakeCCompilerId.c:20:52: error: expected ‘,’ or ‘;’ before ‘COMPILER_ID’
 char const* info_compiler = "INFO" ":" "compiler[" COMPILER_ID "]";
                                                    ^~~~~~~~~~~

[...]

Furthermore, I'd like to ask: Why is json-c a dependency in the first place ?

$ LC_ALL=C guix describe
Generation 124  Sep 18 2020 22:27:08    (current)
  guix e6ba735
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: e6ba735d685886e747a831e43a501488e15d97c7
  heads 50b97d4
    repository URL: https://github.com/daym/heads-guix.git
    branch: wip-musl
    commit: 50b97d446ebafd0be7a0e19d87cd236882093244

[Message part 2 (application/pgp-signature, inline)]

Message #8 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Sat, 19 Sep 2020 23:05:14 +0200

[Message part 1 (text/plain, inline)]

More info:

https://gitlab.kitware.com/cmake/cmake/-/issues/20568

https://gitlab.kitware.com/utils/kwsys/-/merge_requests/187

> Furthermore, I'd like to ask: Why is json-c a dependency in the first place ?

Because of sdl2.  I've removed sdl2 from the native-inputs of u-boot
and added it to the native-inputs of u-boot-tools in guix master
commit 6b1253718d1d660e7a91bd59a96bdb16d7c5e0b3.

So now only this fails:

$ guix build -s armhf-linux u-boot-tools

[Message part 2 (application/pgp-signature, inline)]

Message #11 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: 43513 <at> debbugs.gnu.org, <ludo <at> gnu.org>
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Mon, 21 Sep 2020 14:22:26 +0200

[Message part 1 (text/plain, inline)]

Hi,

I found the underlying cause of the problem with qemu transparent emulation:

* qemu transparent emulator has 64 bit registers
* the thing it's emulating has 32 bit registers
* The glibc in the distro that is running in the emulator is using getdents64
(on 32 bits!) and then (rightfully) checking whether d_off and the inode number
fit into their own (32 bits/entry) struct, which they don't (the thing they get
from the kernel is 64 bits/entry).

See also https://lore.kernel.org/lkml/20181229015453.GA6310 <at> bombadil.infradead.org/T/
for an analysis.

See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960 for a discussion.

Least-shitty workaround: Use a 32-bit qemu (yes, a qemu compiled on 32 bit)
on a 64 bit machine for transparent emulation of ANOTHER 32-bit machine.
That way, the kernel can know that there's a 32 bit user lurking somewhere up
the call chain that is calling getdents64 and is not actually able to process the
result.  "The truth?  It can't handle the truth."

The right fix: One could also tell all the packages in the emulated
system to use the large file size API (-D_FILE_OFFSET_BITS=64 and co).  In this
case cmake is affected--but it could be any number of things.  I think that that
is the only good fix (we could also add a compile-time check whether <dirent.h>
has been included without anyone specifying -D_FILE_OFFSET_BITS=64--that would
make finding these problems a LOT easier; if possible, emit that compile-time
error only if readdir is actually called anywhere).

For the workaround, we could adapt Guix system's gnu/services/virtualization.scm
so it uses a qemu built for the 32-bit variant of the host architecture if it's
emulating a 32 bit system.

So qemu could be compiled for i686 if the host is x86_64 and the emulated
system is armhf,
qemu could be compiled for armhf if the host is aarch64 and the emulated system
is armhf and so on.

That also means that if a host system is 64 bits and DOES NOT HAVE a 32 bit
pendant target, then the emulation of a 32 bit system is going to be imperfect.

One way to fix that would be to fix the kernel to accept an argument on
the getdents64 syscall (and similar ones) that tells it whether the user wants
to have 64 bit offsets or 32 bit offsets[1].  Right now, from user space, that
is only possible via process personality flags.  And those would switch the
entire qemu executable over to 32 bits, which we don't want (qemu itself has
to do stuff using kernel syscalls, so it needs to be capable of 64 bits
if it itself is 64 bits).  And I think that even that case is not being
handled in the kernel correctly.  So this fix cannot be done.

@Ludo:

Anyway, I have a question on how to replicate what "guix build --target=i686..."
does, in the guix service definition.  How can I make it use
package-cross-derivation instead of package-derivation ?
See attachment.

With the attachment and the service definition

            (service qemu-binfmt-service-type
             (qemu-binfmt-configuration
              (platforms (lookup-qemu-platforms "arm"))
              (guix-support? #t)))

in order to emulate ARM on x86_64 I eventually get:

>Building qemu-minimal for i686

(That's what I want!)

>[...]
>starting phase `configure'
>
>ERROR: pkg-config binary 'i686-unknown-linux-gnu-pkg-config' not found

pkg-config has not been cross-compiled...

That's because it's not using package-cross-derivation, I guess.

>command "./configure" "--cc=/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/gcc" "--host-cc=/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/gcc" "--disable-debug-info" "--enable-virtfs" "--prefix=/gnu/store/80ljf47lrh8arrzjmkrrqxghc0k67b3s-qemu-minimal-5.1.0" "--sysconfdir=/etc" "--cross-prefix=i686-unknown-linux-gnu-" "--target-list=i386-softmmu,x86_64-softmmu" failed with status 1

I think that "--cc" should use ,(cc-for-target) at all times.

Better this:

diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 53e9dde125..bf712afd4a 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -227,7 +227,7 @@
                (setenv "LDFLAGS" "-lrt")
                (apply invoke
                       `("./configure"
-                        ,(string-append "--cc=" (which "gcc"))
+                        ,(string-append "--cc=" ,(cc-for-target))
                         ;; Some architectures insist on using HOST_CC
                         ,(string-append "--host-cc=" (which "gcc"))
                         "--disable-debug-info" ; save build space

[1] A way for userspace to tell the kernel that is to use getdents instad of
getdents64 on 32 bits, like it used to.  But they don't want to do that anymore.

Another way would be for qemu to translate a syscall getdents64 from the guest
to getdents on the host if the machine they are emulating is 32 bits.  But that
would mean that getdents on a 64 bit host would still have to act like it's
32 bits and translate the d_off accordingly.  That's not guaranteed[2].

Or even using the old readdir syscall.

[2] Linux-5.8.8:

[... CONFIG_COMPAT ...]
SYSCALL_DEFINE3(getdents, unsigned int, fd,
                struct linux_dirent __user *, dirent, unsigned int, count)
{
        struct fd f;
        struct getdents_callback buf = {
                .ctx.actor = filldir,
                .count = count,
                .current_dir = dirent
        };
        int error;

        f = fdget_pos(fd);
        if (!f.file)
                return -EBADF;

        error = iterate_dir(f.file, &buf.ctx);
        if (error >= 0)
                error = buf.error;
        if (buf.prev_reclen) {
                struct linux_dirent __user * lastdirent;
                lastdirent = (void __user *)buf.current_dir - buf.prev_reclen;

                if (put_user(buf.ctx.pos, &lastdirent->d_off))
                        error = -EFAULT;
                else
                        error = count - buf.count;
        }
        fdput_pos(f);
        return error;
}
It's not guaranteed.

[services-qemu-transparent-emulation-make-more-exact.patch (text/x-patch, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #14 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Mon, 21 Sep 2020 14:23:59 +0200

[Message part 1 (text/plain, inline)]

Kernel side: https://bugzilla.kernel.org/show_bug.cgi?id=205957

[Message part 2 (application/pgp-signature, inline)]

Message #17 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Mon, 21 Sep 2020 14:44:41 +0200

[Message part 1 (text/plain, inline)]

> to have 64 bit offsets or 32 bit offsets[1].  Right now, from user space, that
> is only possible via process personality flags.

Or via CONFIG_X86_X32, which exposes extra syscalls ON x86_64 ONLY.

I guess that would be better than nothing--although glibc would have to look
seriously strange to use those:  Even on ARM, it would have to try this syscall
first, and then the normal one.  I don't think that that is reasonable to add
to glibc.

[Message part 2 (application/pgp-signature, inline)]

Message #22 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 12:13:40 +0200

Hi Danny!

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> I found the underlying cause of the problem with qemu transparent emulation:
>
> * qemu transparent emulator has 64 bit registers
> * the thing it's emulating has 32 bit registers
> * The glibc in the distro that is running in the emulator is using getdents64
> (on 32 bits!) and then (rightfully) checking whether d_off and the inode number
> fit into their own (32 bits/entry) struct, which they don't (the thing they get
> from the kernel is 64 bits/entry).

Looks very much like the CMake-on-emulated-hardware issue several of us
encountered before:

  https://issues.guix.gnu.org/38454#3
  https://issues.guix.gnu.org/42448

Glad you found an explanation!

(I see you also posted <https://issues.guix.gnu.org/43591>.)

> See also https://lore.kernel.org/lkml/20181229015453.GA6310 <at> bombadil.infradead.org/T/
> for an analysis.
>
> See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960 for a discussion.

Woow.

> Least-shitty workaround: Use a 32-bit qemu (yes, a qemu compiled on 32 bit)
> on a 64 bit machine for transparent emulation of ANOTHER 32-bit machine.
> That way, the kernel can know that there's a 32 bit user lurking somewhere up
> the call chain that is calling getdents64 and is not actually able to process the
> result.  "The truth?  It can't handle the truth."

OK.

> The right fix: One could also tell all the packages in the emulated
> system to use the large file size API (-D_FILE_OFFSET_BITS=64 and co).  In this
> case cmake is affected--but it could be any number of things.  I think that that
> is the only good fix (we could also add a compile-time check whether <dirent.h>
> has been included without anyone specifying -D_FILE_OFFSET_BITS=64--that would
> make finding these problems a LOT easier; if possible, emit that compile-time
> error only if readdir is actually called anywhere).

Yes; that user-space should be built with -D_FILE_OFFSET_BITS=64 is also
the conclusion at
<https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c32>.

Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a
graft for CMake wouldn’t help because CMake is used at build time.)

> +(define (closest-cross-compiled-qemu qemu target-bits)
> +  "Cross-compile QEMU for the given TARGET-BITS platform that is closest to
> +the actual host architecture, if possible.  This is in order to prevent
> +https://lore.kernel.org/lkml/20181229015453.GA6310 <at> bombadil.infradead.org/T/"
> +  (define (cross-compiled-qemu target)
> +    (package
> +      (inherit qemu)
> +      (arguments
> +       (substitute-keyword-arguments (package-arguments qemu)
> +        ((#:configure-flags flags)
> +         `(cons ,(string-append "--cross-prefix=" target "-")
> +                ,flags))))
> +      (native-inputs
> +        `(("cross-gcc" ,(cross-gcc target))
> +          ("cross-binutils" ,(cross-binutils target))
> +          ,@(package-native-inputs qemu)))))
> +  (match target-bits
> +   (64 qemu)
> +   (32 (match (register-width (%current-system))
> +        (32 qemu)
> +        (64 (match (%current-system)
> +             ("x86_64-linux"
> +              (cross-compiled-qemu (nix-system->gnu-triplet "i686-linux")))
> +             ("aarch64-linux"
> +              (cross-compiled-qemu "arm-linux-gnueabihf"))
> +             (_ (begin
> +                   ;; TODO: Print warning
> +                   qemu))))))))

It doesn’t make sense to cross-compile from x86_64 to i686.  Instead we
should use a native build, but an i686 one:

  (package/inherit qemu
    (arguments `(#:system "i686-linux" ,@(package-arguments qemu))))

Likewise for AArch64/ARMv7.

How does that sound?

Thanks,
Ludo’.

Message #29 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 13:13:22 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Fri, 25 Sep 2020 12:13:40 +0200
Ludovic Courtès <ludo <at> gnu.org> wrote:

> Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a
> graft for CMake wouldn’t help because CMake is used at build time.)

Sure--cmake upstream will fix it anyway and make a new release.

But I now opened bug# 43591 on guix-patches in order to find all the OTHER
problems this causes we didn't see yet.  I already ran it on my laptop in
order to find all the users trying to stick a 64-bit value into a 32-bit
slot and it looks very bad--there are instances of this problem in libstdc++,
binutils bfd etcetc.

I suggest to delete all ARM substitutes that were built on x86_64 machines
and disable the builders using x86_64 to build ARM stuff in the mean time.
What that has built is VERY MUCH not reliable since readdir() was broken
sporadically--and compilers need that :P

> It doesn’t make sense to cross-compile from x86_64 to i686.  Instead we
> should use a native build, but an i686 one:
> 
>   (package/inherit qemu
>     (arguments `(#:system "i686-linux" ,@(package-arguments qemu))))

Sure.

I'm still hoping we can skip the workaround and do the right thing instead
(compiling everything with -D_FILE_OFFSET_BITS=64 regardless of architecture).

I thought this matter with making everyone use LFS was settled in about
2007--but no, here we go again :(

Even if we did the workaround with qemu here, that still means the kernel
(via a compatibility layer) is going to lie to qemu about file offsets and
directory entry hashes.  That doesn't sound good for reproducibility.

Also, I want to be clear that qemu is not at fault here.

It's fundamentally unsound to call getdents64 and expect a value with less
than 64 bits back.  But that is what glibc does.

Users (other packages) who use _FILE_OFFSET_BITS=32 (by not setting
_FILE_OFFSET_BITS at all) in 2020, those are at fault.

> Likewise for AArch64/ARMv7.

I do not think the X86_32 compatibility layer works on aarch64, so now we have
a problem.  That means building stuff for ARMv7 on aarch64 is not reliable at
all.

The right fix is to always use "-D_FILE_OFFSET_BITS=64" in user space.  Then
none of this weird stuff needs to be done.

[Message part 2 (application/pgp-signature, inline)]

Message #32 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 13:18:56 +0200

[Message part 1 (text/plain, inline)]

On Fri, 25 Sep 2020 13:13:22 +0200
Danny Milosavljevic <dannym <at> scratchpost.org> wrote:

> I do not think the X86_32 compatibility layer works on aarch64, so now we have
> a problem.  That means building stuff for ARMv7 on aarch64 is not reliable at
> all.

Hmm.

Could I have access to a aarch64 build machine?  Or am I able to cause
a aarch64 build machine to evaluate a new wip branch?

I want to find out what it actually does in the case that aarch64 is used to
run armv7 stuff.  Does it have a compat layer in the kernel or not?

How about all the other 64 bit architectures that have a 32 bit compat
fallback in hardware?  Do those have a compat layer in the kernel or not?

[Message part 2 (application/pgp-signature, inline)]

Message #35 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 18:00:05 +0200

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> On Fri, 25 Sep 2020 13:13:22 +0200
> Danny Milosavljevic <dannym <at> scratchpost.org> wrote:
>
>> I do not think the X86_32 compatibility layer works on aarch64, so now we have
>> a problem.  That means building stuff for ARMv7 on aarch64 is not reliable at
>> all.
>
> Hmm.
>
> Could I have access to a aarch64 build machine?

You’re listed in overdrive.scm in maintenance.git, so you must have
access to overdrive1.guixsd.org:52522.

Ludo’.

Message #38 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 18:02:54 +0200

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> On Fri, 25 Sep 2020 12:13:40 +0200
> Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a
>> graft for CMake wouldn’t help because CMake is used at build time.)
>
> Sure--cmake upstream will fix it anyway and make a new release.
>
> But I now opened bug# 43591 on guix-patches in order to find all the OTHER
> problems this causes we didn't see yet.  I already ran it on my laptop in
> order to find all the users trying to stick a 64-bit value into a 32-bit
> slot and it looks very bad--there are instances of this problem in libstdc++,
> binutils bfd etcetc.

Hmm, it’s this bad?

> I suggest to delete all ARM substitutes that were built on x86_64 machines
> and disable the builders using x86_64 to build ARM stuff in the mean time.
> What that has built is VERY MUCH not reliable since readdir() was broken
> sporadically--and compilers need that :P

What are the odds of a build succeeding in the presence of broken
getdents/readdir?  Wouldn’t such builds simply fail (as in the CMake
case), as opposed to succeeding but somehow producing invalid binaries?

We can still disabled emulated builds on ci.guix.gnu.org, but let’s
first make sure we understand the practical impact of this bug.

> I thought this matter with making everyone use LFS was settled in about
> 2007--but no, here we go again :(

Yeah.  :-/

Ludo’.

Message #41 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 18:23:26 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Fri, 25 Sep 2020 18:02:54 +0200
Ludovic Courtès <ludo <at> gnu.org> wrote:

> What are the odds of a build succeeding in the presence of broken
> getdents/readdir?  Wouldn’t such builds simply fail (as in the CMake
> case), as opposed to succeeding but somehow producing invalid binaries?

I don't know what hashing mechanism ext4 uses, but I guess the odds are not
that high IF THE DIRECTORY IS RANDOM.  If it's crafted by a malicious person,
all bets are off.

However, notice that glibc can only fail out of readdir once it gets an *actual*
value >= 2**32.  It's totally possible in principle to have a directory with
200 entries, the first 100 of which have d_off < 2**32, and the 101st has
d_off >= 2**32.  Readdir will only stop after having given back 100 entries
to the caller.  The caller most likely will process those 100 entries.
That's it, you've just forgotten to install/copy/read/whatever half the files.

Technically the caller could examine errno to find out that something bad
happened while using readdir, but odds are that they don't (I haven't seen
anyone do that in my entire career)--and also the error code they are using
is undocumented[1].  So even a person who would check wouldn't expect this
error value (errno == EOVERFLOW).  In short, it won't work in practice.

> We can still disabled emulated builds on ci.guix.gnu.org, but let’s
> first make sure we understand the practical impact of this bug.

We need non-emulated builds to compare.

If a real ARM machine uses substitutes for anything, it probably picks up
now-untrustworthy builds made by x86_64 for ARM and builds on top of those.

Or don't they use substitutes?
In that case everything would be OK-ish.
Otherwise huge mess...

[1] "man getdents64" does not list EOVERFLOW--at least not for me.

[Message part 2 (application/pgp-signature, inline)]

Message #44 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 18:25:42 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Fri, 25 Sep 2020 18:00:05 +0200
Ludovic Courtès <ludo <at> gnu.org> wrote:

> You’re listed in overdrive.scm in maintenance.git, so you must have
> access to overdrive1.guixsd.org:52522.

Indeed, I do.

Thanks!

[Message part 2 (application/pgp-signature, inline)]

Message #47 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Fri, 25 Sep 2020 18:37:20 +0200

[Message part 1 (text/plain, inline)]

> [1] "man getdents64" does not list EOVERFLOW--at least not for me.

I meant "man readdir"

[Message part 2 (application/pgp-signature, inline)]

Message #50 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Sat, 26 Sep 2020 12:53:20 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Fri, 25 Sep 2020 18:25:42 +0200
Danny Milosavljevic <dannym <at> scratchpost.org> wrote:

> On Fri, 25 Sep 2020 18:00:05 +0200
> Ludovic Courtès <ludo <at> gnu.org> wrote:
> 
> > You’re listed in overdrive.scm in maintenance.git, so you must have
> > access to overdrive1.guixsd.org:52522.  
> 
> Indeed, I do.
> 
> Thanks!

I'd like to test what happens if one builds json-c on an aarch64 host
for i686.

Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

One machine is enough--I'd just run

  guix environment -s i686-linux gcc-toolchain -- gcc -o a00 -D_FILE_OFFSET_BITS=xxx a00.c

and then later

  guix build -s i686-linux json-c

on it.

a00.c:

#include <stdio.h>
#include <errno.h>
#include <assert.h>
#include <dirent.h>
#if defined( __ILP32__ )
#warning ILP32
#endif

int main() {
        DIR* d;
        struct dirent* ent;
        d = opendir("tmp");
        errno = 0;
        assert(sizeof(ent->d_off) == sizeof(off_t));
        while ((ent = readdir(d)) != NULL) {
                printf("off=%llX, ino=%llX\n", (unsigned long long) ent->d_off, (unsigned long long) ent->d_ino);
        }
        if (errno)
                perror("readdir");
        return sizeof(off_t);
}

[Message part 2 (application/pgp-signature, inline)]

Message #53 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying to
 build u-boot
Date: Sat, 26 Sep 2020 19:20:29 +0200

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:
> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

I am working (or rather, the machine is compiling) to set it up on dover.
When it is finished, I will keep you updated (it may take a while, since
I did a "guix pull", and now it will also compile a new kernel).

Andreas

Message #56 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying to
 build u-boot
Date: Sun, 27 Sep 2020 11:50:27 +0200

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:
> I'd like to test what happens if one builds json-c on an aarch64 host
> for i686.
> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?
> One machine is enough--I'd just run
>   guix environment -s i686-linux gcc-toolchain -- gcc -o a00 -D_FILE_OFFSET_BITS=xxx a00.c
> and then later
>   guix build -s i686-linux json-c

you can give it a try on dover.guix.info, but you should be ready for
a wait: As other build machines, it does not use substitutes, so everything
will be built locally using qemu-binfmt. Maybe you could import what
is needed for the "guix environment" from an i686 machine?

I would suggest to do a "guix pull --commit=0939462e3f81bc98b38bdb7610e6a80ca1cbaa1b",
since this is the version already available on the machine.

Andreas

Message #59 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Andreas Enge <andreas <at> enge.fr>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Sun, 27 Sep 2020 13:32:59 +0200

[Message part 1 (text/plain, inline)]

Hmm, /home/dannym is missing there.  I can log in but not pull.

[Message part 2 (application/pgp-signature, inline)]

Message #62 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Tue, 29 Sep 2020 12:25:54 +0200

Hi,

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> I'd like to test what happens if one builds json-c on an aarch64 host
> for i686.
>
> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?

I think you can just run ‘qemu-i386 /path/to/your/program’; no need for
the whole binfmt_misc shebang.

HTH,
Ludo’.

Message #65 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andreas Enge <andreas <at> enge.fr>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Tue, 29 Sep 2020 12:43:08 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Tue, 29 Sep 2020 12:25:54 +0200
Ludovic Courtès <ludo <at> gnu.org> wrote:

> > I'd like to test what happens if one builds json-c on an aarch64 host
> > for i686.
> >
> > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?  
> 
> I think you can just run ‘qemu-i386 /path/to/your/program’; no need for
> the whole binfmt_misc shebang.

Sure, but I want to know what happens to json-c.  That sounds like a lot of
manual invocations (like about 20000--for invocations of "configure", "gcc",
including all the dependencies etcetc).

Andreas Enge already tried to configure dover.guix.info to uses qemu-binfmt
to emulate i686-linux, but apparently it doesn't work (on dover.guix.info):

building /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv...
\builder for `/gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv' failed with exit code 1
build of /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv failed
View build log at '/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2'.

bash-5.0$ bzless /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2
------> /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2 <------
while setting up the build environment: executing `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory

[Message part 2 (application/pgp-signature, inline)]

Message #68 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Tue, 29 Sep 2020 13:05:11 +0200

[Message part 1 (text/plain, inline)]

On Tue, 29 Sep 2020 12:43:08 +0200
Danny Milosavljevic <dannym <at> scratchpost.org> wrote:

> /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash

Also, this file exists, and is for i686, and if I invoke it using

  /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash -c "echo foo"

then it works (which means the qemu transparent emulation picks it us).

[Message part 2 (application/pgp-signature, inline)]

Message #79 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: Andreas Enge <andreas <at> enge.fr>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Wed, 30 Sep 2020 11:10:17 +0200

Hi,

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> On Tue, 29 Sep 2020 12:25:54 +0200
> Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> > I'd like to test what happens if one builds json-c on an aarch64 host
>> > for i686.
>> >
>> > Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?  
>> 
>> I think you can just run ‘qemu-i386 /path/to/your/program’; no need for
>> the whole binfmt_misc shebang.
>
> Sure, but I want to know what happens to json-c.  That sounds like a lot of
> manual invocations (like about 20000--for invocations of "configure", "gcc",
> including all the dependencies etcetc).

Do we know which bit of json-c’s ‘configure’ draws an incorrect
conclusion?

> Andreas Enge already tried to configure dover.guix.info to uses qemu-binfmt
> to emulate i686-linux, but apparently it doesn't work (on dover.guix.info):
>
> building /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv...
> \builder for `/gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv' failed with exit code 1
> build of /gnu/store/7wz8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv failed
> View build log at '/var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2'.
>
> bash-5.0$ bzless /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2
> ------> /var/log/guix/drvs/7w/z8nqh6nkfqz6l780i6i34c6wa6ic6q-guile-bootstrap-2.0.drv.bz2 <------
> while setting up the build environment: executing `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory

That’s to little context for me to say much (I’d need to see the command
at least) but it could be that it’s trying to run i686 code on ARM or
similar.

Ludo’.

Message #82 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andreas Enge <andreas <at> enge.fr>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying
 to build u-boot
Date: Wed, 30 Sep 2020 13:27:54 +0200

[Message part 1 (text/plain, inline)]

Hi Ludo,

On Wed, 30 Sep 2020 11:10:17 +0200
Ludovic Courtès <ludo <at> gnu.org> wrote:

> Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> 
> > On Tue, 29 Sep 2020 12:25:54 +0200
> > Ludovic Courtès <ludo <at> gnu.org> wrote:

> > Sure, but I want to know what happens to json-c.  That sounds like a lot of
> > manual invocations (like about 20000--for invocations of "configure", "gcc",
> > including all the dependencies etcetc).  
> 
> Do we know which bit of json-c’s ‘configure’ draws an incorrect
> conclusion?

At least I don't.  I don't even have a homedir on dover.guix.info, so I cannot
run guix pull, guix describe, or really anything that is interesting on there.

Andreas knows maybe--it works for him.

> > while setting up the build environment: executing `/gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash': No such file or directory  
> 
> That’s to little context for me to say much (I’d need to see the command
> at least) but it could be that it’s trying to run i686 code on ARM or
> similar.

Note that /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash is an i686 executable
on dover.

Running it just like this

  /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash

it works there on dover!

In order to reproduce the problem, you can log into dover.guix.info and then
run

  guix build -s i686-linux json-c

.

Andreas knows more and can do much more on that machine.

[Message part 2 (application/pgp-signature, inline)]

Message #85 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying to
 build u-boot
Date: Wed, 30 Sep 2020 14:17:31 +0200

Hello,

On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:
> At least I don't.  I don't even have a homedir on dover.guix.info, so I cannot
> run guix pull, guix describe, or really anything that is interesting on there.

this is a problem I have now seen at least three times, so I have opened
its own bug:
   https://issues.guix.gnu.org/43720

Andreas

Message #88 received at 43513 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Andreas Enge <andreas <at> enge.fr>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 43513 <at> debbugs.gnu.org
Subject: Re: bug#43513: json-c build failure (on armhf-linux) while trying to
 build u-boot
Date: Thu, 1 Oct 2020 18:18:59 +0200

Hi,

On +2020-09-30 14:17:31 +0200, Andreas Enge wrote:
> Hello,
> 
> On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:
> > At least I don't.  I don't even have a homedir on dover.guix.info, so I cannot
> > run guix pull, guix describe, or really anything that is interesting on there.
> 
> this is a problem I have now seen at least three times, so I have opened
> its own bug:
>    https://issues.guix.gnu.org/43720
> 
> Andreas
>

At https://issues.guix.gnu.org/43720 it says
--8<---------------cut here---------------start------------->8---
Your may also send email to 43720 <at> debbugs.gnu.org to comment.
--8<---------------cut here---------------end--------------->8---

(Nit: s/Your/You/ :)

I am wondering what the difference is besides the browser interface,
in regards to how the submission gets logged, stored, and re-distributed.

-- 
Regards,
Bengt Richter

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.