blob: f016f42115e6ee5c0f5f29bebf226cf123d8a0d7 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I need to classify this bug report as either 'user-mode' or 'system-mode'. Let me go through the details step by step.
First, the issue occurs when building a Yocto project on an i686 host. The user is using MACHINE = "qemumips64", which means they're emulating a MIPS64 architecture using QEMU. They ran into errors while bitbaking gobject-introspection. The error messages mention something about an 'Address overflow loading ELF binary' when trying to run the compiler.
Looking at the commands, it seems that the build process is invoking qemuwrapper and trying to execute ./.libs/g-ir-compiler. The error suggests there's a problem with the address space of the compiled binary. Since the host is i686 (32-bit), but they're compiling for MIPS64 (which is 64-bit), I think this might be related to how QEMU handles user-mode emulation on a 32-bit host.
The user provided a link to Yocto bug #9285, which likely relates to this issue. From what I remember, QEMU can run in two modes: system mode and user mode. System mode emulates an entire operating system with hardware components, while user mode is used for running executables of different architectures.
In this case, the error seems to be about running a MIPS64 binary on a 32-bit host. User-mode QEMU allows running binaries of other architectures without full OS emulation. However, I've heard that there are limitations when using user-mode QEMU on 32-bit hosts for 64-bit targets because the address space can't properly map.
So, the problem here is likely with user-mode QEMU not handling the MIPS64 binary correctly on a 32-bit host. This would fall under 'user' mode issues since it's about running binaries without full system emulation.
</think>
user
|