syscall_nr.h is generated from syscall_n32.tbl and syscall_n64.tbl, so it should be under your build directory, not the source directory.
But if you did a build before the change, the dependency file .d will store a path in the src dir and the new file will not be generated in the build dir but in the previous place. linux-user/mips64/Makefile.objs: ifeq ($(TARGET_SYSTBL_ABI),n32) %/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n32.tbl $(syshdr) $(call quiet-command, sh $(syshdr) $< $@ n32 "" 6000,"GEN","$@") endif ifeq ($(TARGET_SYSTBL_ABI),n64) %/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n64.tbl $(syshdr) $(call quiet-command, sh $(syshdr) $< $@ n64 "" 5000,"GEN","$@") endif Normally this is cleaned up by the configure with: for arch in alpha hppa m68k xtensa sh4 microblaze arm ppc s390x sparc sparc64 \ i386 x86_64 mips mips64 ; do # remove the file if it has been generated in the source directory rm -f "${source_path}/linux-user/${arch}/syscall_nr.h" # remove the dependency files for target in ${arch}*-linux-user ; do test -d "${target}" && find "${target}" -type f -name "*.d" \ -exec grep -q "${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \ -print | while read file ; do rm "${file}" "${file%.d}.o" ; done done don -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1883560 Title: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build Status in QEMU: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions