After two failing builds, I here re-run it to produce output for my report:
make -j1 V=s > make.stdout 2>make.stderr
. The standart output and standard error files:
-
make.stdout
: → Here, -
make.stderr
: → Here.
(long files.) - Combined stdout and stderr in order from a subsequent run (
make -j1 V=s > make.out 2>&1
): → Here.
From there, the interesting part:
make.stderr
:
[...]
make[2]: /usr/bin/env: Argument list too long
make[2]: *** [package/Makefile:69: package/install] Error 127
make[1]: *** [package/Makefile:109: /home/felics/tmp/owrt/staging_dir/target-i386_pentium-mmx_musl/stamp/.package_install] Error 2
[...]
The previous make
-call was a very long one, a 210800(!) characters long command. From make.stdout
(I cannot copy the whole command line here because it is too long for the forum software. The whole very long command line is → here):
[...]
IPKG_NO_SCRIPT=1 IPKG_INSTROOT=/home/felics/tmp/owrt/build_dir/target-i386_pentium-mmx_musl/root-x86 TMPDIR=/home/felics/tmp/owrt/build_dir/target-i386_pentium-mmx_musl/root-x86/tmp /home/felics/tmp/owrt/staging_dir/host/bin/opkg --offline-root /home/felics/tmp/owrt/build_dir/target-i386_pentium-mmx_musl/root-x86 --force-postinstall --add-dest root:/ --add-arch all:100 --add-arch i386_pentium-mmx:200 install \
/home/felics/tmp/owrt/bin/targets/x86/geode/packages/base-files_1-r16046-59980f7aaf_i386_pentium-mmx.ipk [...] /home/felics/tmp/owrt/bin/packages/i386_pentium-mmx/telephony/sngrep_1.4.8-1_i386_pentium-mmx.ipk
[...]
I have already found this post, where there is a link to this patch. I extracted the patch from the email (→ here the plain patch file),
but it fails to apply (*click* to show):
patch -N --verbose -p1 --dry-run fix_argument_list_too_long.patch
:
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk
|index 5f7f2583a2..f2c31d1d3c 100644
|--- a/include/package-ipkg.mk
|+++ b/include/package-ipkg.mk
--------------------------
checking file include/package-ipkg.mk
Using Plan A...
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED
done
My build path, under ${HOME}/tmp/owrt
, is not something extraordingly long.
Should I report it as a bug to bugs.openwrt.org? Seems that "Argument list too long"-type errors are around for some time already.
Can setting a insanely huge ulimit -s
really be the only viable solution, as layed out in this post and this post and this post? And if that is the case, then I suggest to put into the build-documentation an information about that problem and that some quite high ulimit -s
values might be needed.
Maybe the underlying build system might need a proper rework to not generate and need insanely long argument lists?
My configuration:
- OpenWRT version: 21.02.0-rc1,
- build target: x86, AMD geode (
CONFIG_TARGET_x86_geode=y
), with hand-tuned gcc-optimisations (CONFIG_TARGET_OPTIMIZATION="-O3 -pipe -mtune=geode -march=geode -mmmx -m3dnow -fomit-frame-pointer"
), enabled some but far far away from most packages, -
git describe
:v21.02.0-rc1
, - Latest commit 2021-04-19, commit hasg
2ce89a3
,'git log -n1 --pretty=medium --abbrev-commit --date=iso' (*click* to show):
commit 2ce89a3 (grafted, HEAD, tag: v21.02.0-rc1) Author: [...] Date: 2021-04-19 21:10:14 +0200 OpenWrt v21.02.0-rc1: adjust config defaults Signed-off-by: [...]
(Author details removed by myself for potential privacy reasons.)
-
'feeds.conf' (*click* to show):
src-git packages https://git.openwrt.org/feed/packages.git^4ceeb8fc90ed2c2e650ddddc855e7ed1df071c22 src-git luci https://git.openwrt.org/project/luci.git^7d913b997601d533cca187cfc1b3057c3c98effc src-git routing https://git.openwrt.org/feed/routing.git^5b4d4c7fb6a97cac68c7d8b156fd0ab27bab4dcc src-git telephony https://git.openwrt.org/feed/telephony.git^178822957123b821407e1216e9e7314161512ac6
- OpenWRT
.config
: See → here. (Long file.) -
ulimit -n
:1024
,ulimit -s
:8192
,'ulimit -a' (*click* for details):
real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30804 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 98 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30804 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Further things tried out:
-
- Retried after issuing
ulimit -s unlimited
in the logged-in shell. -
ulimit -Ss
andulimit -Hs
show bothunlimited
after issuing that. - Rebuild.
- Same problem.
- Retried after issuing
-
- Did set for my build user in
/etc/security/limits.conf
the soft and the hard limit forstack
andnofile
both to65535
. - Logout and login (on text console; re-login needed because the PAM-infrastructure does handle settings from that file),
- checked with
ulimit
if those settings had effects. They had. - Rebuild.
- Same problem.
- Did set for my build user in
-
- Did set for my build user in
/etc/security/limits.conf
the soft and the hard limit forstack
tounlimited
and fornofile
to65535
. - Reboot.
- Checked with
ulimit
if those settings had effects. They had. - Rebuild.
- Problem persists.
- Did set for my build user in
Any idea what may be wrong?