readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents64

  • Open
  • quality assurance status badge
Details
4 participants
  • Andreas Enge
  • Bengt Richter
  • Danny Milosavljevic
  • Ludovic Courtès
Owner
unassigned
Submitted by
Danny Milosavljevic
Severity
critical
Merged with
D
D
Danny Milosavljevic wrote on 19 Sep 2020 17:36
json-c build failure (on armhf-linux) while trying to build u-boot
(address . bug-guix@gnu.org)
20200919173628.423331da@scratchpost.org
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
branch: master
commit: e6ba735d685886e747a831e43a501488e15d97c7
heads 50b97d4
branch: wip-musl
commit: 50b97d446ebafd0be7a0e19d87cd236882093244
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9mJXwACgkQ5xo1VCww
uqXbjAf/XpcklLwZJe7z2T1aFt1hpqYme6wgdHZ9AZJC8vPJIAoFQQ1VzNghMkqi
21D+J4QE9uXSif5Ek5pjOFS5Dat3sGBUASstDWs26DALpCfWjhDcZiU6W7R4v1dA
8QXo0oKsrmePmTV/ZhftygyZzE6JQPwJuLlES4mHoIBR8Hu+AisVXkaCUcOEIKC/
yiargZhYIHmZ2YkSOmjPNT+CeVH8BHi+5g3ZBNDmcBF4s/GrJViG95osuA0RMxZk
qT/0uI9jhfinrYMrxNuO0dwDreOclFOKEfmCQ/ylgMUySPVoHeHF4HFKnkZMJAeQ
hK9u8HTGK3V7iky9RpfGQkEeOuRTrQ==
=IlKf
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 19 Sep 2020 23:05
(address . 43513@debbugs.gnu.org)
20200919230514.53f0d88a@scratchpost.org
Toggle quote (2 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9mcooACgkQ5xo1VCww
uqWFrwgAnu0BWfVJXlmf35OE6Z15krkyt4QAjsLMz7mnxSJonL/Itm+4Nm3uGJ8+
qvkYo0YJSGjsSTs9XPkHO+NO6T1c7+UqI/R+Dx9qOSMqW50DZeF5V4E+AOfz/YG+
5CiArR+Kk4P46SduAorDycegs16je/fICsz7K9+nCBxHx6QEXzV0Gst2TjuA3ifo
9dh6WbPY95/0c/kGian4v2+cDcTN/n/g1ENwebKTGXaOx5/0E9dgU+fLYKR5ez6w
UNi3G+8moUvRCl5Md2VwTJU7aU8bZo7l8H0+sO9Y352V05WbRz1On1y7y6uTPbJx
ZHLTZfD9frbWCF9njEJ+l0LllwMyaQ==
=R6xI
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 21 Sep 2020 14:22
20200921134855.2ed40eb0@scratchpost.org
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9omwIACgkQ5xo1VCww
uqUOEAf/f5fivmpMwTEJus4fOX94uPxsd0BYqyeXJ4TKJDlnyxQ3Fn9Ev8H56hb2
CN5ywUbG0bB8yiVvRJmPJxvuCFf4/873wWVgp9U2cBZRwsaHRV6PHcTcyUZ2ERhs
ptY9SjNzuNYwOnyjPh/+mUpm6KrK8strQt8FJSYRj/vPFZ2HUhiwE4wWatRRqxlX
0ic3If+tDIF2Y/wNEZgg03PX73ncjOZ+0syABFt6iyYC7HwVf1tEer9ogL3KQX9E
DbUteMlYy8veppFalQt1pILyRS9hbEJas3nWyfWy3DgXZb2kujIzixJpoUHEpf3z
RY97rNeURQEBgkVACHR2kUOwWiAipg==
=beSN
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 21 Sep 2020 14:23
(address . 43513@debbugs.gnu.org)
20200921142359.37a60189@scratchpost.org
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9om18ACgkQ5xo1VCww
uqVyuwgAjRUKQmnnS3xzdOhQZf155cu2I0o8Gmh7agRjSQbqmXcpTuaQ1rhFvml9
2B5WXWrFxPf0eG/vwOL9mLsw6naC/YyUfC+yF3BUODJqNjIkj33DZWNKETXNQHuR
4ZHpMrFp+75iH1tKFXq3gfTunlCcmcvtG2wx3X5u8q8ZyMBvhESyclBlK2xFKYvG
4GWnK5JGGT9c0GsnSfHR40AWuPq5FXIt3gqVpe7oVk60FkJjO411hVuodRWTfADV
PKLC4LqDiPkj36uT1olXKVhcQCQ5BT+LmAPmH3GqxDkapI/Q9NmBfMXUXK8OYxiP
sLGU6fDcc+a7dPDYf4u3yql9IET+DQ==
=0of2
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 21 Sep 2020 14:44
(address . 43513@debbugs.gnu.org)
20200921144441.4b58d775@scratchpost.org
Toggle quote (3 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9ooDkACgkQ5xo1VCww
uqUIOAf9ESCd+on4RNsqrv6/EGlu39MMapytX5Vz/GxIKC6yQGD+Y+yuIqsU7Pm3
Y7jDvoAolLRxYBSlAQqxuRz7apud8jl83xiVdPL7w40EJxvPu5z9ofNpcLg2ZqgE
aB18RGkt679HAJ0hjEMJFJ3tlAEoXNk25xhlRFzSpazJwPHk9yRz4Hf8N58dOk6h
zDOxThOBIJu7o7xwc/Wc2GnLQkZk020mKwwXMH2Iz8Q+tkcRMrXvYcOytHLFGuPV
SBliyxMkXsJ2Z0mYFoZd8l4N1UOY99bz8XnVIcjEN7vv5mcgrU5KEKir32zFqq2G
dl15Dmr0vpRNxiRH2lTixhYikTXw4g==
=oAi2
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 25 Sep 2020 11:57
control message for bug #43513
(address . control@debbugs.gnu.org)
87eemq2n7g.fsf@gnu.org
merge 43513 42448
quit
L
L
Ludovic Courtès wrote on 25 Sep 2020 12:13
Re: bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)
87wo0i17vv.fsf@gnu.org
Hi Danny!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (9 lines)
> 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:


Glad you found an explanation!

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

Toggle quote (5 lines)
> for an analysis.
>
> See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960 for a discussion.

Woow.

Toggle quote (6 lines)
> 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.

Toggle quote (8 lines)
> 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

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

Toggle quote (29 lines)
> +(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’.
L
L
Ludovic Courtès wrote on 25 Sep 2020 12:14
control message for bug #43513
(address . control@debbugs.gnu.org)
87v9g217uk.fsf@gnu.org
retitle 43513 'getdents' misbehaves when emulating 32-bit code on a 64-bit-kernel host
quit
L
L
Ludovic Courtès wrote on 25 Sep 2020 12:14
(address . control@debbugs.gnu.org)
87tuvm17uf.fsf@gnu.org
severity 43513 important
quit
D
D
Danny Milosavljevic wrote on 25 Sep 2020 13:13
Re: bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200925131237.32fc61e9@scratchpost.org
Hi Ludo,

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

Toggle quote (3 lines)
> 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

Toggle quote (6 lines)
> 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.

Toggle quote (2 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9t0NIACgkQ5xo1VCww
uqVZFQf7ByjxtzbOpP5VuFBPsuWRsXJvHOYhpTJLXkgLv0/sDx7Xp0PDvlE7Ec99
Scd7US21nTu1z7SKJoI1RcKJ4vPZQYefobr9a6NYUaXz99J+4rp2x77U+IT+DzIN
k+3Z/4kMv6rHZ8iJkB5tVM9H3MJSY8CIxGBPdVlLyi1Uap2eY2r/B3Yi+59wz2jD
R3Mz4OBUg5jlqIJwcW7/0LRLxU2PGny42pPlX7DukVUExhoGNiGSMgkt9W/GludP
op/9wOKaKFk48vdsUbsLgal9p/bfSn0qKnKXkju2B6T1iD5HFJ0XOpsA9OTcnTbr
qO1EZEuUuUZLbfU0Pz8Ovoooe7f2tg==
=6a2J
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 25 Sep 2020 13:18
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200925131856.4a1d4a1c@scratchpost.org
On Fri, 25 Sep 2020 13:13:22 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:

Toggle quote (4 lines)
> 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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9t0iAACgkQ5xo1VCww
uqWRhAgAiK9kxke/Y5MRBMMip3RNCRplrWBFwN1bR3TOM0aCTkwW80J674ByTVom
iY8wzBxZnqWU3KJ4TboL5Sm0TsgnRum7b7WpZRq1uEnwPs2nYpJWxWfStL0zzSrM
F0Et1nqzJ2N6dk57UTQgDFwTuGCiEx2D1DuV2j6HkqO52wN5MqhuefoP4EgS5bOU
t2cDnkol3+x40QvY7t0Z/pEOOiXHY90xLrCbf/zEEEK8XZ9GOFkx9C2Ieo6PM4r0
cT8TMC1WSA6b5ubpLrZPIr6k2H3L6sBMf+UZKUO6hof0o3KwgliLEsXI7WFR1Xl8
V76v+LHZkzOPLN9PK0+for6M+S3j3Q==
=Jzv8
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 25 Sep 2020 18:00
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)
874knlkfsq.fsf@gnu.org
Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (11 lines)
> 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’.
L
L
Ludovic Courtès wrote on 25 Sep 2020 18:02
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)
87wo0hj13l.fsf@gnu.org
Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (14 lines)
> 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?

Toggle quote (5 lines)
> 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.

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

Yeah. :-/

Ludo’.
D
D
Danny Milosavljevic wrote on 25 Sep 2020 18:23
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200925182326.402aa6f2@scratchpost.org
Hi Ludo,

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

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9uGX4ACgkQ5xo1VCww
uqWi9wgAm4mQhsA+mCqSiaPLDJr7y7QuqAZ/xU9WjKqIbGCQHZJZyveeOr64B2OV
xDuVXzn2yc/P4Ot3mMm1+EuW85FXKcIG3y7xwd5kA0+d0oSfHBQOrBru2Xw7ezMD
734V3Fh79KzHSjhL/rBrdl3dJ+nwRas5Ap5jKJpgtB15HKDqyPS1F6+Sooxmxr/J
SKuEd8vwsKrS+WmDpTWJoWh1BJkcqQsIOl9rA1kk1WlYU25buysKHSdFzUmZ1EBN
d/F8+O5B1/jBQM8EpEkYjG2LvgWX1oqizP9UZ9G3OZ8lM1NaYF+13hdtWtJhJMNn
OwHKPnuFRI4lzqpUzMyM35MCPhHE3A==
=E3hj
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 25 Sep 2020 18:25
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200925182542.72f556d2@scratchpost.org
Hi Ludo,

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

Toggle quote (3 lines)
> You’re listed in overdrive.scm in maintenance.git, so you must have
> access to overdrive1.guixsd.org:52522.

Indeed, I do.

Thanks!
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9uGgYACgkQ5xo1VCww
uqVtjQf/fvkjp0Dpk+qXGVyCj52AwXSMQHw9DjM4jGM1WMusae6SZj7jJqHVpwsm
E8s+3FLRtw3F3b2e05Ofpsl69/EBjtU1zIFw93WBQE83wny/qc95zzEBsh7PZrNA
tN3/g4R96qUDCCP9iS5xk2en61swStoWINWr7mNd9Oarm5HYanZ5Se/uJZJLQwHf
/Zcyom/LoNXB4uc6W0hyBve957wD8vjexdxTa/RrfoxawCZtzCgFKNXEEVWi025V
Ok+tjC/3VSLVkN6qi/kmjAhk7rkFj7DFQY01xUuhEFRixYbI/rwbtJ0pkGh+PSM4
aHfOdoE12WbkqITS2GGsez6lD1IXKg==
=WltV
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 25 Sep 2020 18:37
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200925183720.472220de@scratchpost.org
Toggle quote (2 lines)
> [1] "man getdents64" does not list EOVERFLOW--at least not for me.

I meant "man readdir"
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9uHMAACgkQ5xo1VCww
uqWPgwgAlEg9jMLx/WDB7tbrQuwH2EzkGU/Kd+XaWmezgmcBenkbR/E2gQIquN8m
8SubKQWmMpBEi0sEJe7Xm4t2AgsDXTIwoYFEWGz3Ob6d724RCaiY5vAhwhdcEKMS
ZOusM++HAD3afRdfW0RUU7LjdWy3X3sM04sO39+M6fU8OBfrd+kJmb7l81NCGt/o
FPal1q7ntzmsyaDnjGA9eo1P3GV9Tid+WW5jn9pqmBqvK4jwaJstZo7F2TYpzFe6
K7F66kcZe5iJvsJawFgJWZePGwhdZBuohbgR0AtQdp05H5WA7wSg8nhJcG+BWkib
1LYIW66/9gdqeOWV8n6dGretG5DK/A==
=Cvxp
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 26 Sep 2020 12:53
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200926125320.11b8f4be@scratchpost.org
Hi Ludo,

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

Toggle quote (10 lines)
> 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);
}
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9vHaAACgkQ5xo1VCww
uqXtogf+Nsm7FF9rNtoFKQU6QQS0q9cOTYmSlcmgbVifSTgf82aObAGBP9XeQnS3
i/IhZj22IcLYbvNCrryR1+qhyR+e29fqCQhHzUBPxBDH8NarCag4URFfZyAE0k4X
qL4YfRs8KEQgd2DOBzGbvbNAQyYS1fKN1SONNiYs/lXn2lfwPrFVildy7E1XuZ23
CsTFrxCsPDHZI2NkfImuh13ucKLoXd56eU3xqNNNAHbilIohBZU1gmA052TZ4rhN
3YBbA3VvZ5OM/2Dy1X4wR8aWO1pENaqOUaZXsceQmkqpAYlWn1XAcfCYGodg3vMa
xJfFVgFbeALCanzBm3fGmD78Nl7W7Q==
=adFG
-----END PGP SIGNATURE-----


A
A
Andreas Enge wrote on 26 Sep 2020 19:20
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
20200926172029.GA9866@jurong
Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:
Toggle quote (2 lines)
> 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
A
A
Andreas Enge wrote on 27 Sep 2020 11:50
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
20200927095027.GA4962@jurong
Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:
Toggle quote (8 lines)
> 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
D
D
Danny Milosavljevic wrote on 27 Sep 2020 13:32
(name . Andreas Enge)(address . andreas@enge.fr)
20200927133259.6e7b1421@scratchpost.org
Hmm, /home/dannym is missing there. I can log in but not pull.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9weGsACgkQ5xo1VCww
uqUPhggAl3WZajX0fTSW6g/A5mjeOm7SSajiYvfB/Db/nCkt5EWWCGB9dNR3ga6Q
SHfkXl50rRb1Z9IOM5KgRSccn+02DYMwuuFjx+M2bM1UobQENBYol3sYT2ONPVvV
DrdkhrVIw2So57InLnL9kbwQYlJ+5Ee6UTyDuAwoqEmzDGKE34NiQ6I1i0MGqRTX
X6Be/slhUFBQC9c4H5T+C9wUYFf13j0AltTh7E6yoNArI2+7vmSSyl2NpV0lMofb
EZ5LGs1qXPPVTU+BQd2lA3g73y6SmtBT/go48pJ9kH9Fvj+h1ySYjR67Oo5Cpj47
NjcUUsWSnWLyUN2CxMNAyGpU6hCtBw==
=HDkZ
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 29 Sep 2020 12:25
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 43513@debbugs.gnu.org)
87a6x87ubx.fsf@gnu.org
Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (5 lines)
> 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’.
D
D
Danny Milosavljevic wrote on 29 Sep 2020 12:43
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200929124308.419282f2@scratchpost.org
Hi Ludo,

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

Toggle quote (8 lines)
> > 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
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zD7wACgkQ5xo1VCww
uqXxOQgAnzYeIszNvkOwEVAx96x6JBXDB1ZHXv+3QTYFN7qb0nn/griHPTzO+q0M
CWyhqRQ4K0oU3JKV4Msud1aTsLjPLECebHavShn1t5ZMb18DCKOCWLvZ5PDCdeC6
VXoMAtwVTIlblpFtvLJ4B2q09B8lQwKuL9LdEFTHLFFbUMy7IPdkgcVPYudnatgH
RdwqIqB7KFfoDqUUHCexbcGuKeVgr1tuPS+Z+zTEUmepXIcApVHu7qGI9LD6ziUE
QIL9x/aw3AT6XzQBCWg116ZZKj1DoGZpaEfyK6Rvb0Y6gGwCLt2bs+mGmt2bfrrb
rqBP7yXe6LwAyRm0BeLilVw1T3hsng==
=V10v
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 29 Sep 2020 13:05
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43513@debbugs.gnu.org)
20200929130511.4573c01f@scratchpost.org
On Tue, 29 Sep 2020 12:43:08 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:

Toggle quote (2 lines)
> /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).
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zFOcACgkQ5xo1VCww
uqWIOggAodueuItVyBGluXBGH/oC96g2r4/kRNPx6+Sd9i0p1AMgw34F8oxIohDd
sX8QqkYNPY77l1oKKZjpMhbuKRBgxyID/uF3v9a/aIe1uwK0wsHTds0TU36juxmh
Twjwwr4FlnVojNvC3lHCHo9WR3zRsA8QxS7YewgCL3ZT3aUMOGcjSXNmBjxgS+7g
EPm3tz58UvxGGjgVy5EX2IbF64ltEYs//quE+JuoGzjHCL/37acFnz2phkiHbgsw
nEpR+GrPAVDq5E6IPvtWDmuTeH0720qClji17VNcxUxies/E86FLmXGktw/6q5zw
J+kk/0MyBiWAPrM1ePZKS7vo1HErLA==
=zZOQ
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 29 Sep 2020 16:33
(no subject)
(address . control@debbugs.gnu.org)
20200929163351.5f4aaaef@scratchpost.org
retitle 43513 Kernel/userspace interface mismatch between 32 bit user space and 64 bit kernel - readdir
severity 43513 critical
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zRc8ACgkQ5xo1VCww
uqXoQwf9E71eEjVgRLRop9FEB21gtLzhbqDSDq3llhh1BTPgOezXvD4F0YcdxTCe
ToecJ5KazcNeNa1TPTOMLGQpXiygARS6ChkHKdDBNwS9X0K6tLw1ISqdAauZywor
nQcwlHPXB728388oYdueR3HMhqyOiEOaDeG4dBBQsvG90zbW2CtqeI4IV4BKzW0d
m2MLF6D8cc686en5VQQJ9k/M5p5tIOF32zsiXJA87r26eUuJgJ35gNM6dDrtfpeQ
1w2Iq2fAkPJlC8EcsxeD6/wkLb/l9Yq8GjnZUoH/VS6qcHBtsFzjDH0OoqDHY81K
6PJSsoP1Chrods0rPMfkeBAIqom+Nw==
=0ldn
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 29 Sep 2020 16:36
(address . control@debbugs.gnu.org)
20200929163651.7919a847@scratchpost.org
retitle 43513 readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zRoMACgkQ5xo1VCww
uqVIngf/V/5uxj7DVEyvzqDiikzSoMTebV2zJF8h7PlFsGG7qPrd9tXodGJ5sMek
oFVK5vZr5zcmOjrJ14ofj8jJrqzDwUzUVTwecacrGhJElhm7DAbZ9P6zaK2v9IQk
RfR9A6snXsfkeoXtXwfFJOvTIi1jYJdw6UaXfdFRLPQfeMriworyLTFisNKlHa7i
BdjdHLO2Yarozn0k0pYwKmGp/x08sUIeybJA2LcDXnKePftSjl8iKIiciswdecsF
BM13psk+0UXmdspTNRBRLPacv4Bqcr+QZcXmVlmA9FvxsDlX+inF6zZa1zCO4d7G
LGmMovzAKDllnIFUe7T5OnW/MQaD0w==
=NHr1
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 29 Sep 2020 16:39
Re:
(address . control@debbugs.gnu.org)
20200929163953.184425f1@scratchpost.org
retitle 43513 readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents64
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9zRzkACgkQ5xo1VCww
uqU5Zwf9Hhmuk712W2fHePU8CZxCbn6DbMvVRstCiCwY9D3c8ZhFZUlG8SgY4ana
XpppykP6ORCteMqFQwGIN1e3PS2jet6J954t7MqmrrSYWjFkObdr2L/PNd6iH/8w
NJtbgfA8oM56yYiguqh5CWD5XcG9AcYFunKPIqUnWTtl5i6+kUGK9coUAln1H1ny
9753eRTHXNQcobZWTsXHzPmm8Q0YYXEzeTkTy/3oFoMp3zdWnvV7Q22WugYwAqgE
nlgTJdxheIYPz1z9wBE9ZnAvvCGYWu3eJ+hvn/UAluXKt1jC6MSy1htaCgoqG5zL
WVj46zPEluPcDDg9EqNRLGwW+rTixw==
=JleQ
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 30 Sep 2020 11:10
Re: bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
87k0wb3a12.fsf@gnu.org
Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (15 lines)
> 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?

Toggle quote (12 lines)
> 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’.
D
D
Danny Milosavljevic wrote on 30 Sep 2020 13:27
(name . Ludovic Courtès)(address . ludo@gnu.org)
20200930132754.1d88c9e2@scratchpost.org
Hi Ludo,

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

Toggle quote (12 lines)
> 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.

Toggle quote (6 lines)
> > 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl90a7oACgkQ5xo1VCww
uqVqAAf/Z6BV36FrHOP04WNhLmgtoTtrV4FlVa6GAL//+ZCt5AClXWxxaj7wPOwJ
dd28/ygiXt41fcu8+7tYx8FDjzs2Xc7TE590JbvxjVIwsGEQZHLf/daAuHDTiM6M
HvMBM2GCEQeBYP/ZjxulwulN10vhZk5dj6/VZlLbi17VKemZ2NM21DvqJyC/+kzH
IiJELmFvlzXa8nUuEDQyh0R4lDlUFASjMl82vzAe0Ju2L6i+hKXz0JrySK2BtGze
Y5do8Cofc3Gou54bWUgq1AXcG/76JMN/0aA9vqN7k9CCRcMHSz0+dpzC5xFdv+FN
ew45vtGkbQg/jp0BKqyjTplZr+/xTw==
=FDcY
-----END PGP SIGNATURE-----


A
A
Andreas Enge wrote on 30 Sep 2020 14:17
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
20200930121731.GB1632@jurong
Hello,

On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:
Toggle quote (3 lines)
> 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:

Andreas
B
B
Bengt Richter wrote on 1 Oct 2020 18:18
(name . Andreas Enge)(address . andreas@enge.fr)
20201001161859.GA3342@LionPure
Hi,

On +2020-09-30 14:17:31 +0200, Andreas Enge wrote:
Toggle quote (13 lines)
> 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
>

Toggle snippet (3 lines)
Your may also send email to 43720@debbugs.gnu.org to comment.

(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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 43513@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 43513
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch