summaryrefslogtreecommitdiff
path: root/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.7.bb
AgeCommit message (Collapse)AuthorFiles
2013-03-02linux-libc-headers: update to v3.8Bruce Ashfield1
Now that the 3.8 kernel has been released we can bump the libc-headers to that version and remove the 3.7 variant. Userspace compatibility is maintained through kernel versions, we also make the single 3.8 version the toolchain default. 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>
2013-01-10linux-libc-headers: fix headers install in long path name environmentsBruce Ashfield1
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 Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-07linux-libc-headers: add 3.7 versionMarcin Juszkiewicz1
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>