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

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

More info:

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

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

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.

merge 43513 42448

quit

Hi Danny!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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

Woow.

OK.

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

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

retitle 43513 'getdents' misbehaves when emulating 32-bit code on a 64-bit-kernel host

quit

severity 43513 important

quit

Hi Ludo,

On Fri, 25 Sep 2020 12:13:40 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

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

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.

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.

On Fri, 25 Sep 2020 13:13:22 +0200

Danny Milosavljevic <dannym@scratchpost.org> wrote:

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?

Danny Milosavljevic <dannym@scratchpost.org> skribis:

You’re listed in overdrive.scm in maintenance.git, so you must have

access to overdrive1.guixsd.org:52522.

Ludo’.

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Hmm, it’s this bad?

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.

Yeah. :-/

Ludo’.

Hi Ludo,

On Fri, 25 Sep 2020 18:02:54 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

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

Hi Ludo,

On Fri, 25 Sep 2020 18:00:05 +0200

Ludovic Courtès <ludo@gnu.org> wrote:

Indeed, I do.

Thanks!

I meant "man readdir"

Hi Ludo,

On Fri, 25 Sep 2020 18:25:42 +0200

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

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

}

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:

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

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:

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

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

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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

the whole binfmt_misc shebang.

HTH,

Ludo’.

Hi Ludo,

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

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

On Tue, 29 Sep 2020 12:43:08 +0200

Danny Milosavljevic <dannym@scratchpost.org> wrote:

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

retitle 43513 Kernel/userspace interface mismatch between 32 bit user space and 64 bit kernel - readdir

severity 43513 critical

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

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

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

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

conclusion?

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

Hi Ludo,

On Wed, 30 Sep 2020 11:10:17 +0200

Ludovic Courtès <ludo@gnu.org> 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.

Andreas knows maybe--it works for him.

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.

Hello,

On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:

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

Hi,

On +2020-09-30 14:17:31 +0200, Andreas Enge wrote:

At https://issues.guix.gnu.org/43720it says

(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