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

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

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