There would be an "Argument list too long" error when the TMPDIR is in a
deep dir, for example, when "len(readlink -f TMPDIR) >= 350 (our
supported value is 410)". Use "$(foreach ,,$(shell echo))" to fix it.
There was already a patch which tried to fix this issue, so squash the
current change into the previous one as Bruce suggested.
[YOCTO #5138]
(From OE-Core rev: 4e10c45d7c61ac1ccf8b53ef525ca03d3d458bba)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The autobuilders and their long paths are still triggering errors during
the headers installation. Reinstate the previous patch for this,
after updating for 3.10.
(From OE-Core rev: fe4428fd740b3937007e0a3f893714ff04c33533)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a build is started in a deep directory structure, or in a path with
long directory names the installation of linux-libc-headers will fail
with:
| make[2]: execvp: /bin/sh: Argument list too long
| make[2]: ***
>From within the kernel Makefiles themselves.
The solution is to patch the kernel build rules with the following
change:
[
scripts/Makefile.headersinst: install headers from scratch file
If headers_install is executed from a deep/long directory structure, the
shell's maximum argument length can be execeeded, which breaks the operation
with:
| make[2]: execvp: /bin/sh: Argument list too long
| make[2]: ***
By dumping the input files to a scratch file and using xargs to read the
input list from the scratch file, we can avoid blowing out the maximum
argument size and install headers in a long path name environment.
]
Until this change, or a similar one, is merged into the mainline kernel, this
change should be applied to any 3.7 or greater libc-headers build.
Upstream-status: Pending
(From OE-Core rev: 1e63a3b7b7915d40bb59976a02b9f53968997ed3)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>