fix kernel module build for 5.x kernels

[hgy59]

Description

• enhance kernel source preparation for module build

  • update .config
  • patch tools/lib/subcmd/Makefile to avoid gcc warnings as error
  • disable build of objtool (build still fails, even when libelf-dev is available)

• adjust build parameters

  • remove parameter "M=module" (seems backwards compatible)
  • add parameter OBJECT_FILES_NON_STANDARD=y to avoid the need of objtool

• enable build of kernel modules for epyc7002 and rtd1619b (cdrom and usbserial)

REMARKS:

• the build of linux 5.x kernel modules requires libelf-dev installed (not yet available in spksrc dev env)

Fixes #

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Includes small framework changes

[hgy59]

@th0ma7 as expected the build for rtd1619b and epyc7002 failed, since libelf-dev is not installed yet.

But the build jobs (aarch64-7.1 and x64-7.1) didn't fail, despite the make errors like;

2025-11-03T15:37:56.0707898Z   UPD     include/generated/asm-offsets.h
2025-11-03T15:37:56.0737251Z   CALL    scripts/checksyscalls.sh
2025-11-03T15:37:56.0967860Z   CALL    scripts/atomic/check-atomics.sh
2025-11-03T15:37:56.1173102Z error: Cannot resolve BTF IDs for CONFIG_DEBUG_INFO_BTF, please install libelf-dev, libelf-devel or elfutils-libelf-devel
2025-11-03T15:37:56.1179755Z make[4]: *** [Makefile:1247: prepare-resolve_btfids] Error 1
2025-11-03T15:37:56.1180447Z make[4]: Leaving directory '/github/workspace/spk/synokernel-usbserial/work-aarch64-7.1/linux-rtd1619b-7.1'
2025-11-03T15:37:56.1184950Z make[3]: *** [../../mk/spksrc.cross-kernel-module.mk:63: kernel_module_prepare] Error 2
2025-11-03T15:37:56.1185531Z make[3]: Leaving directory '/github/workspace/kernel/syno-rtd1619b-7.1'

Is this by intention? (I guess not)

PS it is not related to the latest framework update (#6738)

[th0ma7]

Is this by intention? (I guess not)

Indeed no, this should have failed, I'll look into that.

Here's my previous attempt at building newer kernel modules: #6772

Last I played with that it was working fine but some other issue had came up that I don't recall, will have to revisit.

One interesting twist to bring to your attention is this which solved a lot of issues found: https://github.com/SynoCommunity/spksrc/pull/6646/files#diff-5d2e26de07a41a9035f64ce717493e723f7cfbeed8863ca4f4e7badea2f647db

Something else worth mentioning are (and probably worth separating in its own PR?):

• patches for ‎kernel/syno-rtd1619b-7.x and ‎kernel/syno-epyc7002-7.x
• updates to kernel build 72806

[hgy59]

One interesting twist to bring to your attention is this which solved a lot of issues found: https://github.com/SynoCommunity/spksrc/pull/6646/files#diff-5d2e26de07a41a9035f64ce717493e723f7cfbeed8863ca4f4e7badea2f647db

I guess this is the same issue I fixed in #6772 with
disable build of objtool (build still fails, even when libelf-dev is available)
and
add parameter OBJECT_FILES_NON_STANDARD=y to avoid the need of objtool

[th0ma7]

I was hoping to reproduce your build error but as I was using debian-13 image instead I got this, nice job 🚀

spksrc@spksrc13:~/hgy59/spksrc/spk/synokernel-cdrom$ tree work-aarch64-7.2/staging/
work-aarch64-7.2/staging/
├── etc
│   └── synokernel-cdrom.cfg
└── lib
    └── modules
        ├── armada37xx-7.2
        │   └── 4.4.302+
        │       └── drivers
        │           ├── cdrom
        │           │   └── cdrom.ko
        │           └── scsi
        │               └── sr_mod.ko
        ├── rtd1296-7.2
        │   └── 4.4.302+
        │       └── drivers
        │           ├── cdrom
        │           │   └── cdrom.ko
        │           └── scsi
        │               └── sr_mod.ko
        └── rtd1619b-7.2
            └── 5.10.55+
                └── drivers
                    ├── cdrom
                    │   └── cdrom.ko
                    └── scsi
                        └── sr_mod.ko

[th0ma7]

@hgy59 took me two attempts to get this right but fixes merged to master and should now exit on error AND provide relevant error msg related to the right sub-kernel build.

[th0ma7]

Looking good!

[hgy59]

@th0ma7 Have you ever considered to strip the kernel modules?

A full strip is not supported, but we can strip the debug info from *.ko files to make those much smaller.

[th0ma7]

@hgy59 I did back when I added this kernel module functionality but didn't know how to do so and modules failed to work with a full strip so I left it there. Unsure where but there must be a hook somewhere to skip the strip part for kernel modules. Would indeed be nice to figure that out.