blob: 969b00bd3fc1722509fd982a70e06ed1e15654f1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build
From time to time I find check-tcg crashes with a one of the MIPS binaries. The last time it crashed was running the test:
./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-user/threadcount
Inevitably after some time noodling around wondering what could be causing this weird behaviour I wonder if it is a build issue. I wipe all the mips* build directories, re-run configure and re-build and voila problem goes away.
It seems there must be some sort of build artefact which isn't being properly re-generated on a build update which causes weird problems. Additional data point if I:
rm -rf mips64el-linux-user
../../configure
make
then I see failures in mip32 builds - eg:
GEN mipsn32el-linux-user/config-target.h
In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
/home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef
#ifndef LINUX_USER_MIPS64_SYSCALL_NR_H
make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1
make[1]: *** Waiting for unfinished jobs....
which implies there is a cross dependency between different targets somewhere. If I executed:
rm -rf mips*
before re-configuring and re-building then everything works again.
|