[06:55] fragile, that i believe implies you are trying to clean that source on a newer series, ie the kernel source is not 18.04 kernel source [06:56] fragile, if you look at the later kernel sources they supply KW_DEFCONFIG_DIR=$(DEBIAN)/d-i [16:25] I'm having issues building a 3rd party module on 18.04. I believe there may be an issue with the linux-kernel-headers package or whatever is responsible for installing the build scripts in /lib/modules/[version]/build/ [16:27] The module includes linux/module.h, which includes linux/list.h which includes linux/kernel.h which includes linux/linkage.h which tries to include asm/linkage.h but fails with "No such file or directory" [16:32] I can't find any clear information on how the asm directory is supposed to work. Is there supposed to be a symlink somewhere? Or should the build scripts in /lib/modules be adding it to the include path? [16:46] Hmm. gcc appears to be adding -I./arch/x86/include, and arch/x86/include/asm/linkage.h exists. So why does gcc say 'no such file or directory'? [16:47] SystemParadox, well those are used routinly for that to build the dkms packages we ship, so i would expect it to work [16:48] SystemParadox, are you sure you have installed the entire headers package for your kernel, there are two for a specific version/flavour [16:50] apw, I have linux-headers-4.15.0-23-generic and linux-headers-4.15.0-23, although I thought the latter was just a metapackage [16:53] oh now I'm really confused. I ran the failing gcc call with -v and it says: ignoring nonexistent directory "-I./arch/x86/include" [16:53] but it does exist! [16:58] you might try installing a dkms package at random, and if that builds you know the headers are complete [16:59] care to suggest one? [17:02] the file it's complaining about is there. I really don't understand why gcc is ignoring that folder [17:05] brcmwl is quite benign [17:07] that seemed to work fine [17:09] so that would imply that the manner in which you are envoking your local build is wrong in some way [17:11] I ran it with KBUILD_VERBOSE=1 to find out what commands it was actually running [17:12] it changes directory to /usr/src/linux-headers-4.15.0-23-generic and runs a gcc which includes -I./arch/x86/include [17:12] if I change to that directory and run the exact same gcc command, I get the same result [17:13] if I add '-v', it tells me it ignores './arch/x86/include' because it doesn't exist... except that it does! [17:45] apw, ok with some help from the gcc guys we realised there's a problem with the arguments [17:46] it's running "gcc -isystem -I./arch/x86/include" [17:47] apparently -isystem takes an argument, which looks like it should be /usr/lib/gcc/x86_64-linux-gnu/7/include [17:47] at the moment it's trying to use "-I./arch/x86/include" as the argument (including the -I part!) [17:48] but I'm totally lost in the kernel build files. I can't find where those arguments are generated or where gcc is run [18:04] ok the issue arises at /usr/src/linux-headers-4.15.0-23/Makefile, which does NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) -print-file-name=include) [18:04] CC appears to just be 'gcc' [18:05] gcc -print-file-name=include gives /usr/lib/gcc/x86_64-linux-gnu/7/include [18:06] but I guess it's not when this is running the first time? I don't know where to go with this now [18:53] SystemParadox, well there is clearly two spaces in the command line, so it is subbing in '' as that path which is not working [18:53] indeed [18:53] SystemParadox, from what i can it should be something like this: [18:53] Makefile:NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) -print-file-name=include) [18:59] that's what I've got [19:00] shell-cached is some voodoo [19:01] I'm currently trying to work out if somehow the arguments passed from the module's own makefile are messing it up, although everything in the kernel build scripts seems to suggest it tries to reset everything to prevent this [19:12] oo this is odd - if I use make -C /lib/modules/4.15.0-23-generic/build it fails, but this is just a symlink to /usr/src/linux-headers-4.15.0-23-generic. If I use that directly, it works [19:37] aha! deleting .cache.mk has fixed it! [19:37] wish I'd taken a copy of it now to see what was wrong with it === ben_r_ is now known as ben_r