When compiled with a given version of linux-headers, boost may produce code that will not work with older running versions of the kernel. This is apparently an intentional project decision not to support backward compatibility of older running kernels. https://github.com/boostorg/filesystem/issues/173 I don't know of a real-world scenario that doesn't involve old versions of Docker or ancient running kernels (eg, 2.6 / OpenVZ), but since this is a project policy and can silently(!) produce broken software, it should probably be dealt with in some safe manner. (For now, I'm manually downgrading linux-headers to 4.19 when building boost, then re-upgrading thereafter since openssh now requires a newer version.)
Boost 1.77.0 will include these commits: https://github.com/boostorg/filesystem/commit/05de74a000444fa996d05bf95a9316048fdad413 https://github.com/boostorg/filesystem/commit/3e8c8b15f940145481c5eb73bc6c108b5bace1da Do they fix this problem?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > Boost 1.77.0 will include these commits: > https://github.com/boostorg/filesystem/commit/ > 05de74a000444fa996d05bf95a9316048fdad413 > https://github.com/boostorg/filesystem/commit/ > 3e8c8b15f940145481c5eb73bc6c108b5bace1da > > Do they fix this problem? Looks like it fixes the example I'm aware of. Does it reflect a change in upstream's policy, though?
https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux-headers#Random_factoids has some strong statements on independence of linux-headers and running kernel in both ways. Gentoo already very conservatively stabilizes linux-headers older or equal to gentoo-sources to avoid breaking fragile software that accidentally violates the compatibility boundary. If you plan to use kernel even older than currently stable linux-headers you either need to fix it upstream or have an environment with older linux-headers (and probably other older software). With all the breakage caveats that go. Normally software should expect building against linux-headers that does not match running kernel. Linux kernel does not usually upgrade or downgrade in lockstep with userspace.
(In reply to Sergei Trofimovich from comment #3) > https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux- > headers#Random_factoids has some strong statements on independence of > linux-headers and running kernel in both ways. > > Gentoo already very conservatively stabilizes linux-headers older or equal > to gentoo-sources to avoid breaking fragile software that accidentally > violates the compatibility boundary. > > If you plan to use kernel even older than currently stable linux-headers you > either need to fix it upstream or have an environment with older > linux-headers (and probably other older software). With all the breakage > caveats that go. Quite confused. Your wiki page says the exact opposite...? > Normally software should expect building against linux-headers that does not > match running kernel. Linux kernel does not usually upgrade or downgrade in > lockstep with userspace. Boost upstream stated they are unwilling to support that. :(
> https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux-headers#Random_factoids > has some strong statements on independence of > linux-headers and running kernel in both ways. Seems to be contradicting itself. Kernel docs say > [...] but a program built against newer kernel headers > may not work on an older kernel. Whether an application checks for syscalls to be present at runime is another thing, and not mandated or even mentioned by the kernel docs from what I can see. Glibc does such runtime checks precisely so you can build it against newest headers, so that an older program built against old headers works with it. However this "protection" obviously does not extend to programs using the kernel API directly and not via libc. I don't see how boost is in violation of kernel policies here.
(In reply to Luke-Jr from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux- > > headers#Random_factoids has some strong statements on independence of > > linux-headers and running kernel in both ways. > > > > Gentoo already very conservatively stabilizes linux-headers older or equal > > to gentoo-sources to avoid breaking fragile software that accidentally > > violates the compatibility boundary. > > > > If you plan to use kernel even older than currently stable linux-headers you > > either need to fix it upstream or have an environment with older > > linux-headers (and probably other older software). With all the breakage > > caveats that go. > > Quite confused. Your wiki page says the exact opposite...? Wiki page describes expected behaviour out of programs. boost does not conform to it and thus you have to freeze a lot of moving parts to make it work. Most programs don't need fiddling with precise headers versions. > > Normally software should expect building against linux-headers that does not > > match running kernel. Linux kernel does not usually upgrade or downgrade in > > lockstep with userspace. > > Boost upstream stated they are unwilling to support that. :( Implementing the equivalent workarounds downstream is even harder and less rewarding than upstream.
> Wiki page describes expected behaviour out of programs. Where is this "expected behaviour" documented by the authors of the kernel headers?
(In reply to Jannik Glückert from comment #7) > > Wiki page describes expected behaviour out of programs. > > Where is this "expected behaviour" documented by the authors of the kernel > headers? I don't understand the question. Authors of kernel headers don't set expectation on userspace compatibility range. Userspace can decide to pin to specific kernel version and kernel headers version. Gentoo expects that userspace does not do too tight coupling and tries to adapt to a range of kernel headers at build time and range of kernel versions at run time with relevant backwards compatibility code. Otherwise you will get bricked userspace when any of the moving parts upgrades. Other distributions can mandate lockstep atomic upgrade of kernel and all of userspace and ignore the problem completely. But in practice most also provide some flexibility.
(In reply to Jannik Glückert from comment #7) > > Wiki page describes expected behaviour out of programs. > > Where is this "expected behaviour" documented by the authors of the kernel > headers? I don't have a source at present, but it's been stated in the past on LKML that userland programs should not rely heavily on kernel headers. Instead, they need to depend more on the libc headers, which will provide the necessary APIs to the currently-available kernel headers. This was really an issue back in the day before the kernel exposed the "uapi" headers where userland programs would explicitly #include headers in /usr/include/bits/* and /usr/include/asm/*, when they should instead #include the headers in /usr/include/sys/*, which tie to the variants in bits/ and asm/. That's why uapi eventually came around, because it was just generally too much of a losing battle to get userland programs to modify their behavior. I have very vague recollections that procps was once guilty of this, because it sought to use the kernel definition of PAGE_SIZE, which led to problems when PAGE_SIZE != 4K.
Sorry, but I don't see how we can fix this in Gentoo.
(In reply to David Seifert from comment #10) > Sorry, but I don't see how we can fix this in Gentoo. Could slot linux-headers, or use whatever kernel sources are installed, I guess? Currently, I have my /etc/portage/env/dev-libs/boost pre_src_unpack check the installed linux-headers and die unless they're sufficiently old. Then I manually install the older one, build boost, then update linux-headers back. pre_src_unpack() { local current_ver=$(qlist -IC sys-kernel/linux-headers -F '%{PV}') [ "$current_ver" = "${LJR_OLDEST_KERNEL_COMPAT}" ] && return die "linux-headers is currently $current_ver - but you want $LJR_OLDEST_KERNEL_COMPAT" }
(In reply to Luke-Jr from comment #11) > (In reply to David Seifert from comment #10) > > Sorry, but I don't see how we can fix this in Gentoo. > > Could slot linux-headers, or use whatever kernel sources are installed, I > guess? > > Currently, I have my /etc/portage/env/dev-libs/boost pre_src_unpack check > the installed linux-headers and die unless they're sufficiently old. Then I > manually install the older one, build boost, then update linux-headers back. > > pre_src_unpack() { > local current_ver=$(qlist -IC sys-kernel/linux-headers -F '%{PV}') > [ "$current_ver" = "${LJR_OLDEST_KERNEL_COMPAT}" ] && return > > die "linux-headers is currently $current_ver - but you want > $LJR_OLDEST_KERNEL_COMPAT" > } Patches welcome, but I strongly doubt people want to compile against kernel sources because of your usecase.
(In reply to David Seifert from comment #12) > Patches welcome, but I strongly doubt people want to compile against kernel > sources because of your usecase. AFAIK running an older kernel than linux-headers is pretty common for Gentoo users?
