blob: 6a4c1068b0cab3d88fe269c25f223befaa58b5b4 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, I'm looking at this problem where someone is trying to cross-compile LV2 plugins using qemu-arm-static on the Zynthian project. They're encountering an issue where qemu throws a signal 6 (Aborted) during the compilation process. The error message points to a problem in the lv2_ttl_generator when running it under QEMU.
First, I need to understand what's causing this. The error mentions a pthread_mutex_lock assertion failure, which suggests there might be a threading issue or incorrect use of mutexes in the code being run by qemu. Since this is happening during cross-compilation, it could be related to how QEMU emulates certain system calls or handles multi-threading.
I should check if others have encountered similar issues with QEMU and pthread_mutex_lock. Maybe there's a known bug or workaround. Also, considering that the code runs fine on an actual Raspberry Pi (armv7), but not under qemu, it might be an emulation issue specific to how QEMU handles certain ARM instructions or system calls.
I should look into the version of QEMU they're using. They mentioned versions 2.12.50 and 2.12.0, so maybe this is a regression in those versions. Checking if newer versions of QEMU have fixed this issue would be helpful.
Another angle is to consider if the script or Makefile used in DISTRHO-Ports has any specific requirements that aren't being met under qemu. Perhaps there are environment variables or flags that need adjustment when running under emulation.
I also wonder if compiling with certain optimization flags might expose bugs in QEMU's handling of pthreads. Maybe reducing optimizations could help, but that would just be a workaround until the root cause is addressed.
Testing this locally by setting up a similar environment and running the same commands could provide more insights. If possible, using strace or gdb under qemu to trace where exactly it's failing might pinpoint the issue.
In summary, I'm leaning towards this being a user-mode issue because it's related to how QEMU handles pthread_mutex_lock in user-space applications during cross-compilation. However, without more specific information from debugging tools, it's hard to be certain.
</think>
user
|