DKMS modules fail to build against linux-steamos

[castlec]

Tried compiling myself. Admittedly, I haven't used Arch much and did run pacman -Suy.

make[1]: Entering directory '/usr/lib/modules/5.13.0-valve21-1-steamos-02209-g2a5bdc1102a0/build' CC [M] /home/winesap/source/rtw/rtw89/core.o cc1: error: incompatible gcc/plugin versions cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so make[2]: *** [scripts/Makefile.build:272: /home/winesap/source/rtw/rtw89/core.o] Error 1
https://github.com/lwfinger/rtw89 - this compiles out of box on HoloIso

Here's the arch package.
https://aur.archlinux.org/packages/rtw89-dkms-git

[LukeShortCloud]

The biggest difference between winesapOS and HoloISO is that we rebased SteamOS 3 on-top of the latest Arch Linux packages. One issue we encountered with that is that the linux-steamos kernel is so old it only builds with GCC 11. Arch Linux defaults to GCC 12 currently so we force the build of linux-steamos to use GCC 11. You will also need to build DKMS modules with that older version.

https://github.com/LukeShortCloud/winesapOS#comparison-with-steamos

I am unsure how to do that and am open to suggestions if you have any ideas. Otherwise, this may not be an issue when SteamOS 3.4 is released as a stable update which is the first time Valve has ever updated the Arch Linux packages since January of this year. Either way, we will try to have this addressed for our upcoming winesapOS 3.3.0 release.

[castlec]

Things I have thought about as possibilities:

• Keep the steam packages in their own filesystem and/or root. Layer on the newer packages with an overlayfs. This would enable a chroot and build
• I'm not sure if it's a standard or not but it seems like it's a standard to have dkms in kernel module packages
  for pkg in $@ do; if [[ $pkg == *"dkms"* ]]; then echo "Clobbering GCC to match expected versions" fi
• Is having another version of gcc as simple as setting the root install with pacman -r

[LukeShortCloud]

Thanks for the suggestions, @castlec ! I appreciate your input. Here are my initial thoughts.

• overlayfs
  • We have to rebuild all the SteamOS packages against Arch Linux (or Manjaro). The linux-steamos package is the only complicated one. This feels like too much time and trouble to setup an overlayfs for building the kernel and DKMS modules. For what it's worth, we do a full build of winesapOS in a chroot today.
• Modify DKMS packages
  • Injecting code into the DKMS install scripts for each module may be a good path forward. But I worry about how sustainable this is long-term.
• Pacman root.
  • This has the same long-term sustainability issues as the "Modify DKMS packages" but is cleaner to implement. We could build the DKMS modules in a separate SteamOS chroot and then copy files over.

I'll see if I can create a proof-of-concept of some of these ideas and see how far I can get.

That all being said, I have found the kernel from SteamOS to not be very useful. Valve does not back-port security patches, it's not even based on an LTS kernel (it's based on Linux 5.13, even in the upcoming SteamOS 3.4 which has an Arch Linux rebase) so it has been end-of-life for over a year now, and most (if not all) of the AMD RDNA2 patches that made it special have been upstreamed. I'll be adding the new Linux 6.1 LTS kernel for our upcoming winesapOS 3.3.0 release that has all of the latest changes merged in.

The one good thing about the SteamOS kernel is that it is the only kernel that fully supports the speaker driver for the Steam Deck. Those patches have not been upstreamed yet.

[LukeShortCloud]

I've tried some solutions but they're overly complicated and don't work.

Everything in Linux SteamOS has been merged upstream except for HDR support. I recommend using Linux LTS instead. When SteamOS 3.5 is released, I'll rebase on-top of those packages. They've most recently rebased Linux SteamOS on-top of Linux LTS 6.1 for that upcoming release. That may solve the problem for DKMS modules on Linux SteamOS since they will stop using an unmaintained kernel.

In summary:

• Short-term solution: use Linux LTS
• Long-term solution: wait for Valve to update Linux SteamOS

Related: #561