new virtualbox-modules which are using new linux-mod-r1 class are failing with my custom build kernel. I understand that this is not a problem for gentoo devs in general, but I believe that reason for this failure is an actual error in these new ebuilds, which in normal circumstances in standard environment is hidden. All because change in definition of KERN_DIR variable. Reproducible: Always build.log: >>> Compiling source in /var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work ... * Building vboxdrv module in /var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work ... make -j15 ARCH=x86 V=1 KBUILD_VERBOSE=1 CONFIG_WERROR= CONFIG_MODULE_SIG_ALL= CONFIG_MODULE_COMPRESS_GZIP= CONFIG_MODULE_COMPRESS_XZ= CONFIG_MODULE_COMPRESS_ZSTD= DEPMOD=: STRIP=: CROSS_COMPILE=x86_64-pc-linux-gnu- HOSTCC=x86_64-pc-linux-gnu-gcc HOSTCXX=x86_64-pc-linux-gnu-g++ 'HOSTCFLAGS=-march=znver1 -O2 -pipe -fgraphite-identity -ftree-loop-distribution -floop-nest-optimize -ftree-vectorize' 'HOSTCXXFLAGS=-march=znver1 -O2 -pipe -fgraphite-identity -ftree-loop-distribution -floop-nest-optimize -ftree-vectorize' 'HOSTLDFLAGS=-march=znver1 -O2 -pipe -fgraphite-identity -ftree-loop-distribution -floop-nest-optimize -ftree-vectorize -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro' HOSTPKG_CONFIG=x86_64-pc-linux-gnu-pkg-config CC=/usr/bin/x86_64-pc-linux-gnu-gcc-13 CXX=/usr/bin/x86_64-pc-linux-gnu-g++-13 LD=/usr/bin/x86_64-pc-linux-gnu-ld.bfd AR=/usr/bin/x86_64-pc-linux-gnu-gcc-ar NM=/usr/bin/x86_64-pc-linux-gnu-gcc-nm OBJCOPY=/usr/bin/x86_64-pc-linux-gnu-objcopy OBJDUMP=/usr/bin/x86_64-pc-linux-gnu-objdump READELF=/usr/bin/x86_64-pc-linux-gnu-readelf KERN_DIR=/usr/src/devel/6.3.6-x1/build KERN_VER=6.3.6-x1 all === Building 'vboxdrv' module === make[1]: Entering directory '/var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work/vboxdrv' make V=1 CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /usr/src/devel/6.3.6-x1/build M=/var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work/vboxdrv SRCROOT=/var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work/vboxdrv -j16 modules make[2]: Entering directory '/usr/src/devel/6.3.6-x1/build' make[2]: warning: -j16 forced in submake: resetting jobserver mode. make -C /usr/src/devel/6.3.6-x1/build/build -f /usr/src/devel/6.3.6-x1/Makefile modules /usr/src/devel/6.3.6-x1/Makefile:737: include/config/auto.conf: No such file or directory make[2]: *** [../Makefile:227: __sub-make] Error 2 make[2]: Leaving directory '/usr/src/devel/6.3.6-x1/build' make[1]: *** [/var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work/vboxdrv/Makefile-footer.gmk:133: vboxdrv] Error 2 make[1]: Leaving directory '/var/tmp/portage/app-emulation/virtualbox-modules-7.0.8-r1/work/vboxdrv' make: *** [Makefile:78: vboxdrv] Error 2 * ERROR: app-emulation/virtualbox-modules-7.0.8-r1::gentoo failed (compile phase): 8-r1/work/vboxdrv' This failure was because change in some env. variables: In old ebuilds variables for make are: KERN_DIR="${KV_DIR}" KERN_VER="${KV_FULL}" O="${KV_OUT_DIR}" <-- succeeding while in new ones there is: KERN_DIR="${KV_OUT_DIR}" KERN_VER="${KV_FULL}" <-- failing I believe that old environment variables setting is right one. Am I wrong? Were these variables, ${KERN_DIR} and ${O}, meaning redefined in these past years?
Please attach the full build.log and emerge --info. Could you also explain what the non-standard environment is here exactly?
Yes, what's special about it? That doesn't say much. If it's out-of-source, fwiw pretty sure I did try that with virtualbox-modules (make O=/tmp/kernel and `KERNEL_DIR=/tmp/kernel emerge virtualbox-modules`) and it worked fine with just KERN_DIR=${KV_OUT_DIR}. Albeit I tried a lot of things and I may have forgotten something. Passing O to build modules would be unusual, albeit virtualbox Makefiles does do weird things (I didn't look at the Makefiles that closely, ceamac may know better).
Yeah I retried out-of-source and that bit seems fine at least. Wouldn't hurt to try to build another simple module in case, e.g. app-admin/ryzen_smu -- virtualbox-modules doing special workarounds wouldn't amount to much if it applies to everything.
make -C /usr/src/devel/6.3.6-x1/build/build -f /usr/src/devel/6.3.6-x1/Makefile modules I don't quite get where this line is coming from, I don't see an equivalent in my own build log (e.g. all lines that call "modules" target have V=1 and -j12 for me). Plus there's two build/build which is likely the issue that O= "just happened" to work around. Are your Makefiles modified?
There is something wrong with your configuration, but it's hard to figure out what without having more info. Let's try to figure out where the extra /build and /build/build comes from. Did you override KERNEL_DIR? Please add the output of: ls -l /lib/modules/`uname -r` ls -l /usr/src/linux ls -lL /usr/src/linux ls -l /usr/src/devel/6.3.6-x1
(In reply to Ionen Wolkens from comment #4) > make -C /usr/src/devel/6.3.6-x1/build/build -f > /usr/src/devel/6.3.6-x1/Makefile modules > > I don't quite get where this line is coming from, I don't see an equivalent > in my own build log (e.g. all lines that call "modules" target have V=1 and > -j12 for me). > > Plus there's two build/build which is likely the issue that O= "just > happened" to work around. > > Are your Makefiles modified? Yep, I made changes to them and this is clearly reason why this .../build/build is missing from your logs. My point was that I lived under impression that the variable KERN_DIR should always point to the source - in this specific case /usr/src/devel/6.3.6-x1 while KV_OUT_DIR should point to the target - the directory where the results of the compilation are stored. Which in my env was different from KERN_DIR and actually changed through time. So I make changes to my env and from that moment more then decade ago, I just continued on autopilot. New way from -r1 which makes assignment KERN_DIR="${KV_OUT_DIR}" therefore resulted in error in my present env. Judging by the reaction to the reported bug, however, it seems that this is not a bug, but a feature. So if this change was well thought out by the developers and is now a gentoo way of life, I need to adapt my environment to the new situation. I therefore apologize for making unnecessary waves. Mea culpa. If my assessment of the situation in the previous paragraph is correct, it is possible to close the bug report.
