bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
@ 2020-09-19 15:36 Danny Milosavljevic
  2020-09-19 21:05 ` Danny Milosavljevic
  2020-09-21 12:22 ` Danny Milosavljevic
  0 siblings, 2 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-19 15:36 UTC (permalink / raw)
  To: 43513

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-19 15:36 bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot Danny Milosavljevic
@ 2020-09-19 21:05 ` Danny Milosavljevic
  2020-09-21 12:22 ` Danny Milosavljevic
  1 sibling, 0 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-19 21:05 UTC (permalink / raw)
  To: 43513

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-19 15:36 bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot Danny Milosavljevic
  2020-09-19 21:05 ` Danny Milosavljevic
@ 2020-09-21 12:22 ` Danny Milosavljevic
  2020-09-21 12:23   ` Danny Milosavljevic
                     ` (2 more replies)
  1 sibling, 3 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-21 12:22 UTC (permalink / raw)
  To: 43513, ludo


[-- Attachment #1.1: Type: text/plain, Size: 6193 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: services-qemu-transparent-emulation-make-more-exact.patch --]
[-- Type: text/x-patch, Size: 11665 bytes --]

diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index 20e104f48c..77f15ba07b 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -23,6 +23,7 @@
   #:use-module (gnu bootloader grub)
   #:use-module (gnu image)
   #:use-module (gnu packages admin)
+  #:use-module (gnu packages cross-base)
   #:use-module (gnu packages ssh)
   #:use-module (gnu packages virtualization)
   #:use-module (gnu services base)
@@ -554,12 +555,13 @@ potential infinite waits blocking libvirt."))
 
 ;; Platforms that QEMU can emulate.
 (define-record-type <qemu-platform>
-  (qemu-platform name family magic mask)
+  (qemu-platform name family register-width magic mask)
   qemu-platform?
-  (name     qemu-platform-name)                   ;string
-  (family   qemu-platform-family)                 ;string
-  (magic    qemu-platform-magic)                  ;bytevector
-  (mask     qemu-platform-mask))                  ;bytevector
+  (name     qemu-platform-name)                                 ;string
+  (family   qemu-platform-family)                               ;string
+  (register-width    qemu-platform-register-width)              ;int, in bits
+  (magic    qemu-platform-magic)                                ;bytevector
+  (mask     qemu-platform-mask))                                ;bytevector
 
 (define-syntax bv
   (lambda (s)
@@ -576,123 +578,123 @@ potential infinite waits blocking libvirt."))
 ;;; 'scripts/qemu-binfmt-conf.sh' in QEMU.
 
 (define %i386
-  (qemu-platform "i386" "i386"
+  (qemu-platform "i386" "i386" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00")
                  (bv "\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %i486
-  (qemu-platform "i486" "i386"
+  (qemu-platform "i486" "i386" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00")
                  (bv "\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %alpha
-  (qemu-platform "alpha" "alpha"
+  (qemu-platform "alpha" "alpha" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90")
                  (bv "\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %arm
-  (qemu-platform "arm" "arm"
+  (qemu-platform "arm" "arm" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %armeb
-  (qemu-platform "armeb" "arm"
+  (qemu-platform "armeb" "arm" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %sparc
-  (qemu-platform "sparc" "sparc"
+  (qemu-platform "sparc" "sparc" 32 ; FIXME check
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %sparc32plus
-  (qemu-platform "sparc32plus" "sparc"
+  (qemu-platform "sparc32plus" "sparc" 32 ; FIXME check
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x12")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %ppc
-  (qemu-platform "ppc" "ppc"
+  (qemu-platform "ppc" "ppc" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x14")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %ppc64
-  (qemu-platform "ppc64" "ppc"
+  (qemu-platform "ppc64" "ppc" 64
                  (bv "\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %ppc64le
-  (qemu-platform "ppc64le" "ppcle"
+  (qemu-platform "ppc64le" "ppcle" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00")))
 
 (define %m68k
-  (qemu-platform "m68k" "m68k"
+  (qemu-platform "m68k" "m68k" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x04")
                  (bv "\xff\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 ;; XXX: We could use the other endianness on a MIPS host.
 (define %mips
-  (qemu-platform "mips" "mips"
+  (qemu-platform "mips" "mips" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %mipsel
-  (qemu-platform "mipsel" "mips"
+  (qemu-platform "mipsel" "mips" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %mipsn32
-  (qemu-platform "mipsn32" "mips"
+  (qemu-platform "mipsn32" "mips" 32 ; FIXME check
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %mipsn32el
-  (qemu-platform "mipsn32el" "mips"
+  (qemu-platform "mipsn32el" "mips" 32 ; FIXME check
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %mips64
-  (qemu-platform "mips64" "mips"
+  (qemu-platform "mips64" "mips" 64
                  (bv "\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %mips64el
-  (qemu-platform "mips64el" "mips"
+  (qemu-platform "mips64el" "mips" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %riscv32
-  (qemu-platform "riscv32" "riscv"
+  (qemu-platform "riscv32" "riscv" 32 ; FIXME
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %riscv64
-  (qemu-platform "riscv64" "riscv"
+  (qemu-platform "riscv64" "riscv" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %sh4
-  (qemu-platform "sh4" "sh4"
+  (qemu-platform "sh4" "sh4" 32
                  (bv "\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2a\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %sh4eb
-  (qemu-platform "sh4eb" "sh4"
+  (qemu-platform "sh4eb" "sh4" 32
                  (bv "\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2a")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %s390x
-  (qemu-platform "s390x" "s390x"
+  (qemu-platform "s390x" "s390x" 64
                  (bv "\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x16")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
 (define %aarch64
-  (qemu-platform "aarch64" "arm"
+  (qemu-platform "aarch64" "arm" 64
                  (bv "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff")))
 
 (define %hppa
-  (qemu-platform "hppa" "hppa"
+  (qemu-platform "hppa" "hppa" 32
                  (bv "\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x0f")
                  (bv "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff")))
 
@@ -712,12 +714,48 @@ potential infinite waits blocking libvirt."))
   qemu-binfmt-configuration make-qemu-binfmt-configuration
   qemu-binfmt-configuration?
   (qemu        qemu-binfmt-configuration-qemu
-               (default qemu))
+               (default qemu-minimal))
   (platforms   qemu-binfmt-configuration-platforms
                (default '()))                     ;safest default
   (guix-support? qemu-binfmt-configuration-guix-support?
                  (default #f)))
 
+(define (register-width system)
+  (match (%current-system)
+   ("i686-linux" 32)
+   ("armhf-linux" 32)
+   ("aarch64-linux" 64)
+   ("x86_64-linux" 64)))
+
+(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@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))))))))
+
 (define (qemu-platform->binfmt qemu platform)
   "Return a gexp that evaluates to a binfmt string for PLATFORM, using the
 given QEMU package."
@@ -732,12 +770,13 @@ given QEMU package."
           (bytevector->u8-list bv))))
 
   (match platform
-    (($ <qemu-platform> name family magic mask)
+    (($ <qemu-platform> name family register-width magic mask)
      ;; See 'Documentation/binfmt_misc.txt' in the kernel.
      #~(string-append ":qemu-" #$name ":M::"
                       #$(bytevector->binfmt-string magic)
                       ":" #$(bytevector->binfmt-string mask)
-                      ":" #$(file-append qemu "/bin/qemu-" name)
+                      ":" #$(file-append (closest-cross-compiled-qemu qemu register-width)
+                                         "/bin/qemu-" name)
                       ":"                         ;FLAGS go here
                       ))))
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-21 12:22 ` Danny Milosavljevic
@ 2020-09-21 12:23   ` Danny Milosavljevic
  2020-09-21 12:44   ` Danny Milosavljevic
  2020-09-25 10:13   ` Ludovic Courtès
  2 siblings, 0 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-21 12:23 UTC (permalink / raw)
  To: 43513

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-21 12:22 ` Danny Milosavljevic
  2020-09-21 12:23   ` Danny Milosavljevic
@ 2020-09-21 12:44   ` Danny Milosavljevic
  2020-09-25 10:13   ` Ludovic Courtès
  2 siblings, 0 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-21 12:44 UTC (permalink / raw)
  To: 43513

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-21 12:22 ` Danny Milosavljevic
  2020-09-21 12:23   ` Danny Milosavljevic
  2020-09-21 12:44   ` Danny Milosavljevic
@ 2020-09-25 10:13   ` Ludovic Courtès
  2020-09-25 11:13     ` Danny Milosavljevic
  2 siblings, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2020-09-25 10:13 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

Hi Danny!

Danny Milosavljevic <dannym@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@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@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’.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 10:13   ` Ludovic Courtès
@ 2020-09-25 11:13     ` Danny Milosavljevic
  2020-09-25 11:18       ` Danny Milosavljevic
  2020-09-25 16:02       ` Ludovic Courtès
  0 siblings, 2 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-25 11:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

Hi Ludo,

On Fri, 25 Sep 2020 12:13:40 +0200
Ludovic Courtès <ludo@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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 11:13     ` Danny Milosavljevic
@ 2020-09-25 11:18       ` Danny Milosavljevic
  2020-09-25 16:00         ` Ludovic Courtès
  2020-09-25 16:02       ` Ludovic Courtès
  1 sibling, 1 reply; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-25 11:18 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

On Fri, 25 Sep 2020 13:13:22 +0200
Danny Milosavljevic <dannym@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?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 11:18       ` Danny Milosavljevic
@ 2020-09-25 16:00         ` Ludovic Courtès
  2020-09-25 16:25           ` Danny Milosavljevic
  0 siblings, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2020-09-25 16:00 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 25 Sep 2020 13:13:22 +0200
> Danny Milosavljevic <dannym@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’.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 16:00         ` Ludovic Courtès
@ 2020-09-25 16:25           ` Danny Milosavljevic
  2020-09-26 10:53             ` Danny Milosavljevic
  0 siblings, 1 reply; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-25 16:25 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

Hi Ludo,

On Fri, 25 Sep 2020 18:00:05 +0200
Ludovic Courtès <ludo@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!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 16:25           ` Danny Milosavljevic
@ 2020-09-26 10:53             ` Danny Milosavljevic
  2020-09-26 17:20               ` Andreas Enge
                                 ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-26 10:53 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

Hi Ludo,

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

> On Fri, 25 Sep 2020 18:00:05 +0200
> Ludovic Courtès <ludo@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);
}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-26 10:53             ` Danny Milosavljevic
@ 2020-09-26 17:20               ` Andreas Enge
  2020-09-27  9:50               ` Andreas Enge
  2020-09-29 10:25               ` Ludovic Courtès
  2 siblings, 0 replies; 24+ messages in thread
From: Andreas Enge @ 2020-09-26 17:20 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-26 10:53             ` Danny Milosavljevic
  2020-09-26 17:20               ` Andreas Enge
@ 2020-09-27  9:50               ` Andreas Enge
  2020-09-27 11:32                 ` Danny Milosavljevic
  2020-09-29 10:25               ` Ludovic Courtès
  2 siblings, 1 reply; 24+ messages in thread
From: Andreas Enge @ 2020-09-27  9:50 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-27  9:50               ` Andreas Enge
@ 2020-09-27 11:32                 ` Danny Milosavljevic
  0 siblings, 0 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-27 11:32 UTC (permalink / raw)
  To: Andreas Enge; +Cc: 43513

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

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-26 10:53             ` Danny Milosavljevic
  2020-09-26 17:20               ` Andreas Enge
  2020-09-27  9:50               ` Andreas Enge
@ 2020-09-29 10:25               ` Ludovic Courtès
  2020-09-29 10:43                 ` Danny Milosavljevic
  2 siblings, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2020-09-29 10:25 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

Hi,

Danny Milosavljevic <dannym@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’.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-29 10:25               ` Ludovic Courtès
@ 2020-09-29 10:43                 ` Danny Milosavljevic
  2020-09-29 11:05                   ` Danny Milosavljevic
  2020-09-30  9:10                   ` Ludovic Courtès
  0 siblings, 2 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-29 10:43 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

Hi Ludo,

On Tue, 29 Sep 2020 12:25:54 +0200
Ludovic Courtès <ludo@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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-29 10:43                 ` Danny Milosavljevic
@ 2020-09-29 11:05                   ` Danny Milosavljevic
  2020-09-30  9:10                   ` Ludovic Courtès
  1 sibling, 0 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-29 11:05 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

On Tue, 29 Sep 2020 12:43:08 +0200
Danny Milosavljevic <dannym@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).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-29 10:43                 ` Danny Milosavljevic
  2020-09-29 11:05                   ` Danny Milosavljevic
@ 2020-09-30  9:10                   ` Ludovic Courtès
  2020-09-30 11:27                     ` Danny Milosavljevic
  1 sibling, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2020-09-30  9:10 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Tue, 29 Sep 2020 12:25:54 +0200
> Ludovic Courtès <ludo@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’.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-30  9:10                   ` Ludovic Courtès
@ 2020-09-30 11:27                     ` Danny Milosavljevic
  2020-09-30 12:17                       ` Andreas Enge
  0 siblings, 1 reply; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-30 11:27 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

Hi Ludo,

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

> Danny Milosavljevic <dannym@scratchpost.org> skribis:
> 
> > On Tue, 29 Sep 2020 12:25:54 +0200
> > Ludovic Courtès <ludo@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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-30 11:27                     ` Danny Milosavljevic
@ 2020-09-30 12:17                       ` Andreas Enge
  2020-10-01 16:18                         ` Bengt Richter
  0 siblings, 1 reply; 24+ messages in thread
From: Andreas Enge @ 2020-09-30 12:17 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-30 12:17                       ` Andreas Enge
@ 2020-10-01 16:18                         ` Bengt Richter
  0 siblings, 0 replies; 24+ messages in thread
From: Bengt Richter @ 2020-10-01 16:18 UTC (permalink / raw)
  To: Andreas Enge; +Cc: 43513

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




^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 11:13     ` Danny Milosavljevic
  2020-09-25 11:18       ` Danny Milosavljevic
@ 2020-09-25 16:02       ` Ludovic Courtès
  2020-09-25 16:23         ` Danny Milosavljevic
  1 sibling, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2020-09-25 16:02 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 43513

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 25 Sep 2020 12:13:40 +0200
> Ludovic Courtès <ludo@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’.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 16:02       ` Ludovic Courtès
@ 2020-09-25 16:23         ` Danny Milosavljevic
  2020-09-25 16:37           ` Danny Milosavljevic
  0 siblings, 1 reply; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-25 16:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

Hi Ludo,

On Fri, 25 Sep 2020 18:02:54 +0200
Ludovic Courtès <ludo@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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
  2020-09-25 16:23         ` Danny Milosavljevic
@ 2020-09-25 16:37           ` Danny Milosavljevic
  0 siblings, 0 replies; 24+ messages in thread
From: Danny Milosavljevic @ 2020-09-25 16:37 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 43513

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

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

I meant "man readdir"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2020-10-01 16:26 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-19 15:36 bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot Danny Milosavljevic
2020-09-19 21:05 ` Danny Milosavljevic
2020-09-21 12:22 ` Danny Milosavljevic
2020-09-21 12:23   ` Danny Milosavljevic
2020-09-21 12:44   ` Danny Milosavljevic
2020-09-25 10:13   ` Ludovic Courtès
2020-09-25 11:13     ` Danny Milosavljevic
2020-09-25 11:18       ` Danny Milosavljevic
2020-09-25 16:00         ` Ludovic Courtès
2020-09-25 16:25           ` Danny Milosavljevic
2020-09-26 10:53             ` Danny Milosavljevic
2020-09-26 17:20               ` Andreas Enge
2020-09-27  9:50               ` Andreas Enge
2020-09-27 11:32                 ` Danny Milosavljevic
2020-09-29 10:25               ` Ludovic Courtès
2020-09-29 10:43                 ` Danny Milosavljevic
2020-09-29 11:05                   ` Danny Milosavljevic
2020-09-30  9:10                   ` Ludovic Courtès
2020-09-30 11:27                     ` Danny Milosavljevic
2020-09-30 12:17                       ` Andreas Enge
2020-10-01 16:18                         ` Bengt Richter
2020-09-25 16:02       ` Ludovic Courtès
2020-09-25 16:23         ` Danny Milosavljevic
2020-09-25 16:37           ` Danny Milosavljevic

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