I'd like to propose a small improvement for linux-info.eclass. It attempts KERNEL_DIR to set and KBUILD_OUTPUT to something sane, based on currently running kernel version or KERNEL_VER variable. The attached patch is a proof of concept rather then a proper clean implementation. Please share your opinion. Reproducible: Always
Created attachment 337006 [details, diff] Improve kernel source and object directory selection The patch makes linux-info.eclass depend on the /lib/modules/<VER>/{build,source} links rather than /usr/src/linux link. To build a package for a version of the kernel different then currently running one needs to set KERNEL_VER variable to a desired value.
http://sources.gentoo.org/eclass/linux-info.eclass?r1=1.99&r2=1.100
This is not what I meant. As you write it in your comment for Bug #87242 you have /usr/src/linux link, which is exactly what I would like to avoid. The "source/" and "build/" links in the /lib/modules/<VER>/ directory are quite good at pointing at the right directories. Please do remember that they do not need to point to the same directory, although in the default Gentoo setup they do. Could you please reconsider applying my patch or something similar?
Without my patch (as it is now), if there is no /usr/src/linux and/or I want to build for different kernel than I am running now. I need to specify KERNEL_DIR=/usr/src/linux-3.7.10-gentoo KBUILD_OUTPUT=/var/cache/linux-3.7.10-gentoo With my patch nothing more than KERNEL_VER=3.7.10-gentoo is needed as an environment for emerge to build kernel dependent packages.
(In reply to comment #3) the fact that /usr/src/linux is a symlink isn't terribly relevant. it points to the kbuild output directly, and the eclass is capable of bootstrapping itself from there. i have another system where i keep the source at /usr/src/linux-<ver> and use /usr/src/linux as my kbuild output, and the eclass has no problem locating paths. bug 87242 already discusses locating paths via /lib/modules/. the only reason i don't dupe this right away is that that bug is very long and a mess. maybe i should just punt it. (In reply to comment #4) no, you don't. you only have to set one var now -- point KERNEL_DIR to your kbuild output and the eclass will do the rest.
Re: part 1. /usr/src/linux points to the sources. By default/accident this happens to be the same as KBUILD_OUTPUT. Recently I've implemented "--kernel-outputdir" option for genkernel (it's been upstream for some time already) because I think building out of source tree is the right way and linux-info.eclass should not assume that KERNEL_DIR == KBUILD_OUTPUT. (It doesn't, but the way it works isn't clear, see below). Re: part 2. Haven't you meant KBUILD_OUTPUT? linux-info.eclass says # @ECLASS-VARIABLE: KERNEL_DIR # @DESCRIPTION: # A string containing the directory of the target kernel sources. The default value is # "/usr/src/linux" It says *sources* here. All right, I've just tested it and it works as you've said. Your patch enables linux-info.eclass to discover the setup basing on only one variable, however, it messes up with the semantics a bit. If this patch is going to stay I think you should alter that "docstring" too. I still think, that detection via /lib/modules/<ver>/{source,build} is better.
This patch avoids other packages from failing when KBUILD_OUTPUT is set. The solution of setting KBUILD_OUTPUT=<build dir> in /etc/portage/bashrc.d is causing linux-headers and busybox packages to fail. (https://bugs.gentoo.org/show_bug.cgi?id=566496 - linux-headers build fails.) busybox build fails with the below: >>> Configuring source in /var/tmp/portage/sys-apps/busybox-1.23.1-r1/work/busybox-1.23.1 ... * Could not locate user configfile, so we will save a default one make --jobs=9 -j1 -s allyesconfig /var/tmp/portage/sys-apps/busybox-1.23.1-r1/work/busybox-1.23.1/scripts/basic/fixdep.c:414:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied } ^ compilation terminated. make[2]: *** [scripts/basic/fixdep] Error 1 make[1]: *** [scripts_basic] Error 2 make: *** [allyesconfig] Error 2 * ERROR: sys-apps/busybox-1.23.1-r1::gentoo failed (configure phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-apps/busybox-1.23.1-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-apps/busybox-1.23.1-r1::gentoo'`. * The complete build log is located at '/var/log/portage/sys-apps:busybox-1.23.1-r1:20151123-014530.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/sys-apps/busybox-1.23.1-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-apps/busybox-1.23.1-r1/temp/environment'. * Working directory: '/var/tmp/portage/sys-apps/busybox-1.23.1-r1/work/busybox-1.23.1' * S: '/var/tmp/portage/sys-apps/busybox-1.23.1-r1/work/busybox-1.23.1' (null)*(null) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- (null)*(null) LOG FILE: "/var/log/sandbox/sandbox-26199.log" (null)*(null) VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: scripts/basic/.fixdep.d A: /home/j/var/kernel/src/linux-builds/4.1.12-gentoo-20151122111531/scripts/basic/.fixdep.d R: /home/j/var/kernel/src/linux-builds/4.1.12-gentoo-20151122111531/scripts/basic/.fixdep.d C: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/cc1 -quiet -I scripts/basic -MD scripts/basic/.fixdep.d /var/tmp/portage/sys-apps/busybox-1.23.1-r1/work/busybox-1.23.1/scripts/basic/f ixdep.c -quiet -dumpbase fixdep.c -mtune=generic -march=x86-64 -auxbase fixdep -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer -fstack-protector-strong -o /var/tmp/portage/sys-ap ps/busybox-1.23.1-r1/temp/cc61dPwo.s (null)*(null) -------------------------------------------------------------------------------- Can this patch be accepted? It makes sense to have /usr/src/linux point to the source tree and using the /lib/modules/<ver>/build to figure out the build tree.
Is there any overlay that has this patch? I wish this could be merged into the official overlay.
Created attachment 428538 [details, diff] Above patch in git format-patch format
*** Bug 566496 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 87242 ***
