dongcarl
commented at 1:50 AM on July 16, 2021:
member
- Use 4.19 for riscv64 (earliest LTS release w/ riscv64 support)
- Use 4.9 for all others (second-oldest LTS release, released in
combination with glibc glibc 2.24 in Debian stretch)
The chosen commit is the HEAD of Guix's version-1.3.0 branch as of July
15th, 2021.
Also fix visual indenting.
This + the documentation PR should make our Guix system ready for release!
guix: Pin kernel header version
- Use 4.19 for riscv64 (earliest LTS release w/ riscv64 support)
- Use 4.9 for all others (second-oldest LTS release, released in
combination with glibc glibc 2.24 in Debian stretch)
90fd13b954
guix: Bump to version-1.3.0 from upstream
The chosen commit is the HEAD of Guix's version-1.3.0 branch as of July
15th, 2021.
Also fix visual indenting.
e6a94d4446
fanquake added the label Build system on Jul 16, 2021
fanquake added the label Needs Guix build on Jul 16, 2021
dongcarl force-pushed on Jul 16, 2021
fanquake added this to the milestone 22.0 on Jul 16, 2021
fanquake
commented at 6:06 AM on July 16, 2021:
member
Concept ACK - moving back to vanilla / upstream Guix is good. I take that all of your patches have now made it back to upstream?
dongcarl
commented at 6:14 AM on July 16, 2021:
member
I take that all of your patches have now made it back to upstream?
Note that there are also a few other changes that made it in after version-1.3.0 that would remove some of our custom patching in contrib/guix/patches, but they were merged after a yet-unsolved regression was introduced on Guix's master branch, so I think we should stay on version-1.3.0 for now.
fanquake
commented at 1:23 PM on July 16, 2021:
member
I believe his change would be a strict improvement w/re compatibility.
luke-jr
commented at 11:55 PM on July 19, 2021:
member
0.21.1 used bionic, not focal. It appears to have Linux 4.15, so yes, it is still a compat improvement to use 4.9.
I don't care strongly either way, just making an observation.
laanwj
commented at 3:59 AM on July 20, 2021:
member
As said in #bitcoin-core-dev I don't think it should matter much (for backwards compatibility) what version of the kernel we build against as long as libc is linked dynamically. That said it's good to settle on a version to build against, just to avoid variability that causes unpredictable issues.
The syscalls we use directly are:
getrandom was introduced in kernel 3.17
perf_event_open was introduced in Linux 2.6.31
So no problems there.
I did a build and get the same output as @hebasto.
ACKe6a94d44469f90f4dc88a07a5a8587730811c705
fanquake approved
fanquake
commented at 4:22 AM on July 20, 2021:
member
ACKe6a94d44469f90f4dc88a07a5a8587730811c705
I don't think it should matter much (for backwards compatibility) what version of the kernel we build against as long as libc is linked dynamically.
This seems to match my understanding, as well as the advice provided by the glibc docs for when you compiling glibc:
What version of the Linux kernel headers should be used?
The headers from the most recent Linux kernel should be used. The headers used while compiling the GNU C library and the kernel binary used when using the library do not need to match. The GNU C library runs without problems on kernels that are older than the kernel headers used. The other way round (compiling the GNU C library with old kernel headers and running on a recent kernel) does not necessarily work as expected. For example you can't use new kernel features if you used old kernel headers to compile the GNU C library.
Even if you are using an older kernel on your machine, we recommend you compile GNU libc with the most current kernel headers.
The key point being that you should be free to compile glibc against the latest kernel headers, even when targeting machines that are running older kernels.
The idea of compiling glibc against old kernel headers, as some sort of compatibility hack, is explicitly advised against, as then you might run into issues with machines running newer kernels. So, if anything, we could actually be building against even newer headers than what we are using here (maybe something to revisit later).
In any case, this clearly isn't any sort of regression in compatibility (if it even makes sense to call it that), so I think this change is ok as-is.
fanquake merged this on Jul 20, 2021
fanquake closed this on Jul 20, 2021
luke-jr
commented at 6:06 AM on July 20, 2021:
member
I don't think it should matter much (for backwards compatibility) what version of the kernel we build against as long as libc is linked dynamically.
Unfortunately, Boost explicitly doesn't support running with kernels older than the one used to build. There is an actual bug of this nature that affects Bitcoin Core in some unusual cases. #21550 (However, the version we use in depends should be unaffected anyway - though I can't say I've looked into every potential kernel-header use)
sidhujag referenced this in commit 9886454142 on Jul 23, 2021
gwillen referenced this in commit 434d3e7779 on Jun 1, 2022
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-05-01 03:14 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me