Messages in this thread | | | Subject | Re: Kernel build system broken in 5.8? | From | Martin Burnicki <> | Date | Tue, 18 Aug 2020 22:50:43 +0200 |
| |
Hello Masahiro,
Masahiro Yamada wrote: > On Wed, Aug 19, 2020 at 1:14 AM Martin Burnicki > <martin.burnicki@meinberg.de> wrote: [...] >> I usually build the kernel module as standard user, and only install the >> new module as root, e.g.: >> >> git checkout devel # The 'devel' branch is appropriate for testing >> cd mbgclock # the subdirectory of the kernel module >> git clean -fd; make # or make V=1 for verbose output >> sudo make install > > > This is a bad way for reporting a bug > because your project is too big.
Sorry for this. I wasn't sure which was the best way to get a contact to folks who are more familiar with details of the kernel build system, and what may have been changed.
A possibility could have
> mbgclock/Makefile include the top Makefile, > which is more than 1000 lines.
If you run 'make' in the mbgclock subdirectory then the kernel build system is just called as usual, i.e.
make -C <path-to-the-kernel-build-system> M=$PWD <some EXTRA_CFLAGS>
This has been working without problems for many years, for many popular distros, and all kernels from 2.6 up to 5.7 (except that for older kernels SUBDIRS=$PWD was used instead of M=$PWD).
> Please provide steps to reproduce it > with a tiny test module.
I was just hoping that someone had an idea like "Oh, this is because xyz has changed in kernel 5.18" when he read what I've observed.
In the past I've seen cases where folks e.g. from RedHat or SuSE had backported patches from newer kernels to older ones, causing build errors in my driver code, and I was able to apply workarounds to my source code.
However, this case is different because obviously the kernel source tree is modified under certain circumstances. Is my assumption correct that this should not happen if I install Linux header packages for a distro, that have been pre-configured according to the running kernel?
Anyway, I'm going to try to set up an example which makes it easier to duplicate the problem.
> You state 5.7.15 was fine.
Yes.
> So, could you also run git-bisect, please?
Sorry, I've just recently started using git, and yet I'm not too familiar with some of the commands. How could git-bisect help in this case?
>> Also, I was under the impression that the kernel source tree should be >> read-only, and kept clean, but this doesn't seem to be the case anymore. >> >> >> For example: >> >> On Ubuntu 19.10 with kernel 5.8.1-050801-generic from >> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8.1/ > > > I cannot try it since that is not what > I install on my machine, sorry.
What distro are you using? Or do you only run kernels you have compiled yourself? ;-)
> Please provide steps to reproduce it > for a person using a different environment.
I'm going to try to do this. Do you have any hints what this should look like?
Should this topic be continued on linux-kernel@, or better on linux-kbuild@, or elsewhere?
Thanks,
Martin -- Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/
Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
| |