Remove kernel -I include from userland example to prevent conflicting declaration errors

[cirosantilli]

Before this commit building against kernel v5.10.236 (latest under v5.10 which is the latest minor the README claims to work) was failing with errors such as:

cc -O2 -fomit-frame-pointer -Wall -I/home/ciro/bak/git/linux-kernel-module-cheat/submodules/ldd3/../../data/linux/v5.10/include    mapper.c   -o mapper
In file included from /usr/include/stdlib.h:514,
                 from mapper.c:27:
/usr/include/x86_64-linux-gnu/sys/types.h:42:18: error: conflicting types for ‘loff_t’; have ‘__loff_t’ {aka ‘long int’}
   42 | typedef __loff_t loff_t;
      |                  ^~~~~~
In file included from /home/ciro/bak/git/linux-kernel-module-cheat/submodules/ldd3/../../data/linux/v5.10/include/linux/limits.h:6,
                 from /usr/include/x86_64-linux-gnu/bits/local_lim.h:38,
                 from /usr/include/x86_64-linux-gnu/bits/posix1_lim.h:161,
                 from /usr/include/limits.h:195,
                 from /usr/lib/gcc/x86_64-linux-gnu/14/include/limits.h:210,
                 from /usr/lib/gcc/x86_64-linux-gnu/14/include/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-linux-gnu/14/include/limits.h:34,
                 from mapper.c:26:
/home/ciro/bak/git/linux-kernel-module-cheat/submodules/ldd3/../../data/linux/v5.10/include/linux/types.h:46:33: note: previous declaration of ‘loff_t’ with type ‘loff_t’ {aka ‘long long int’}
   46 | typedef __kernel_loff_t         loff_t;
      |                                 ^~~~~~

because the build was adding the built kernel's include directory to the build of userland programs, which leads to multiple incompatible definitions of certain types.

I don't think this is ever the correct thing to do, the C standard library should be insulated and work on any kernel new enough on the correct arch.

Removing the include it makes the build work tested on Ubuntu 24.10 amd64 GCC 14.2.0.

[dwalkes]

Thanks!

I've verified this also works on Ubuntu 20.04 and GCC 9.4.0. As long as these two combinations work I'm not sure how much we care about older ones. This has been here since the initial commit so presumably it was required at one time. I wasn't able to figure out when the requirement was removed based on a quick search.

This is making me think about something I've considered doing in the past which is setup some build automation which tests at least the build step across a few different host/kernel combinations. I was thinking of doing this when I went through the Linux kernel version 6 upgrades as a part of updating to latest buildroot/yocto branches this summer but if you are planning more updates maybe now would be a good time to do this. We should also probably update the README at some point when you think we've got sufficient coverage of later host/kernel combinations.

Thanks again for the contributions!

[cirosantilli]

Yes, a GitHub actions that tests builds on a few kernels would be a great addition, probably latest supported 4.X, 5.X, 6.X and so on. A simple "build on Ubuntu host toolchain" would already be a good start. But I'm not planning on doing it now haha :-

More seriously, I'm just playing quickly here in a mega hurry for an interview prep, but if I keep coming back one day I'll do it. I was interested in 6.6 and by commenting out readme stuff, there seem to be only two outstanding issues to fix the build at least:

• some stuff in tiny_tty that may be fixed at Modify the code to support Linux 6.x #86
• a issue in short

but those could be a bit harder so I'm not going to look into them now, I was mostly after scull which was working.

[cirosantilli]

And yes, thanks for the maintenance work on this repo, keeping LDD3 alive is a noble cause.

[dwalkes]

Yes, a GitHub actions that tests builds on a few kernels would be a great addition, probably latest supported 4.X, 5.X, 6.X and so on. A simple "build on Ubuntu host toolchain" would already be a good start. But I'm not planning on doing it now haha :-
More seriously, I'm just playing quickly here in a mega hurry for an interview prep, but if I keep coming back one day I'll do it

Sure and to be clear I wasn't asking/expecting you to do this just trying to decide if I should prioritize it now myself.

Good luck with your interview!