Hi everyone,
I build snapshot images for my TP-Link Archer C20 v5 regularly — usually every 1–2 weeks. For a very long time I never had major issues, but for the past two weeks my build has started failing with this error:
make[2] package/install
make -r world: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/home/salman/work/openwrt/include/toplevel.mk:233: world] Error 1
What I’m doing (same workflow as always):
Pull latest changes from master branch
git pull
Update + install feeds
./scripts/feeds update -a
./scripts/feeds install -a
I have been doing this same workflow, but only recently the snapshot build started failing. There were no changes in my .config at first — and even after regenerating a fresh config, the error still appears.
What I need help with
Is there a known issue in the recent master branch affecting ramips / mt76x8 builds?
What’s the recommended way to debug this kind of failure?
Should I upload logs from make -j1 V=s here?
Thanks in advance. Please let me know what other info I should provide.
You should at least look at the sensible log from the single-threaded build with verbose logging. Just posting here the above three lines that basically just say that "it does not work" doesn't give us any clues.
(Look at the verbose single-threaded log, and post only the relevant errors from the end.)
Based on the buildbot faillogs, no cmake related problems any more.
Thanks for the suggestions. I found the cause of the build failure. It wasn’t OpenWrt itself, but my build environment.
During the build with make -j1 v=s, I noticed this message:
find: The relative path 'Files/JetBrains/IntelliJ' is included in the PATH environment variable, which is insecure in combination with the -execdir action of find. Please remove that entry from $PATH
Some Windows paths were accidentally appended to my WSL $PATH, and that was breaking the build process. After removing the Windows paths from $PATH, the OpenWrt snapshot build completed successfully.
So the issue was caused by an incorrect environment setup, not by the OpenWrt source.