Fix elfkickers CI race by disabling parallel make

[zardus]

Summary

• fix intermittent elfkickers build failure in CI (toolcheck (elfkickers)) caused by a parallel make race
• serialize the ELFkickers build in elfkickers/install by changing make -j $(nproc) to make -j1

Why

rebind links against ../elfrw/libelfrw.a, but ELFkickers upstream Makefile does not fully express dependency ordering under parallel builds. In CI this can cause:

/usr/bin/ld: ../elfrw/libelfrw.a: error adding symbols: file format not recognized

Running make single-threaded in this installer removes the race deterministically.

Validation

• bash -n elfkickers/install
• cloned BR903/ELFkickers and ran make -j1 successfully
• verified artifacts elfrw/libelfrw.a and bin/rebind are produced

[Copilot]

Pull request overview

This PR fixes an intermittent build failure in CI for the elfkickers tool by disabling parallel make. The issue stems from race conditions in the upstream ELFkickers Makefile that cause builds to fail non-deterministically when multiple jobs run simultaneously.

Changes:

• Modified the elfkickers install script to use single-threaded make (-j1) instead of parallel make (-j $(nproc))

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Consider adding a comment explaining why -j1 is necessary here. Since this deviates from the repository's convention of using make -j $(nproc) for parallel builds (seen in gdb, qemu, valgrind, etc.), a brief comment would help future maintainers understand this is a workaround for upstream Makefile race conditions. For example: # Use -j1 to avoid race conditions in upstream ELFkickers Makefile

Suggested change

	cd ELFkickers
	cd ELFkickers
	# Use -j1 to avoid race conditions in upstream ELFkickers Makefile

[Copilot]

This installer clones a third-party repository from https://github.com/BR903/ELFkickers without pinning it to an immutable commit and then immediately runs make, effectively granting that external code execution in your CI environment. If the GitHub account or repository is compromised, an attacker can inject malicious build steps to exfiltrate CI secrets or tamper with the generated binaries. To mitigate this supply-chain risk, pin the clone to a specific trusted commit or release and add integrity verification before building.

Example of the risky pattern:

git clone --depth 1 https://github.com/BR903/ELFkickers
cd ELFkickers
make -j1