Guix: Fix building for i686-linux-gnu

luke-jr commented at 6:31 pm on February 27, 2022: member

This seems to be what is needed to get i686-linux-gnu Guix builds working.

Since we don’t officially provide i686-linux-gnu release binaries, I’m not sure if this is wanted for Core. Considering the need to reintroduce --enable-glibc-back-compat, I would guess we don’t want it. But at the same time, our Guix stuff presently has incomplete/broken i686 support, so maybe others might disagree and think it’s worth keeping. (I’m keeping it in Knots for now, so might as well offer it for Core here too.)

Note that for __divmoddi4, I have reintroduced it with a very simple (copyright-immune?) replacement similar to the one used by LLVM. Prior versions (0.17-0.21) using it had copied GPL 3 code from GCC.

Previous versions had also used this __divmoddi4 substitution concept for ARM. As far as I can tell, it was never needed for ARM. While ARM uses a similar method, the equivalent libgcc functions it calls appear to be older than on x86-32.

Also note we cannot use the “build with an older library” trick for __divmoddi4 because it is part of GCC, not glibc, and we require a fairly new GCC to build at all, at this point.

DrahtBot added the label Build system on Feb 27, 2022

DrahtBot added the label Scripts and tools on Feb 27, 2022

DrahtBot added the label Utils/log/libs on Feb 27, 2022

laanwj commented at 11:33 am on February 28, 2022: member

I’m ok with doing the minimal here, but a reminder that supporting i686 is outside the goals of this project. So NACK on reintroducing --enable-glibc-back-compat. It’s ugly, outside scope of maintenance, and as you said yourself on IRC, introducing parts of libgcc into our codebase is legally questionable (dunno about other libraries that look like it like LLVM’s).

Edit: also as said on IRC, with gitian it was the best we could do, as we were bound to ubuntu’s toolchains, with guix we control the entire build environment including toolchains so could patch those if necessary. There’s no excuse for having something like –enable-glibc-back-compat in the leaf bitcoin-core build.

But a more trivial solution is still preferred. Would bumping the minimum libc version for i686 help?

in contrib/devtools/security-check.py:114 in d6b1692608 outdated

110@@ -111,14 +111,22 @@ def check_ELF_separate_code(binary):
111                 return False
112     return True
113 
114+def control_flow_instruction_for(binary):

laanwj commented at 11:37 am on February 28, 2022:

Code review ACK on the security check changes

DrahtBot commented at 2:07 pm on February 28, 2022: member

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

devtools: Port security-check CONTROL_FLOW check to x86-32 ba5aa19c57

devtools: Make test-symbol-check flexible with symbol version value

x86-32 uses 2 instead of 3

0670eb4c74

devtools: Allow libgcc-7 for i686 in symbol-check

GCC 7 introduced the __divmoddi4 function required for x86-32 builds.

This shifts the minimum required Debian version to 10, and Ubuntu to 18.04.
No change to CentOS support (8).

c76ac9d57f

luke-jr force-pushed on Feb 28, 2022

luke-jr commented at 6:06 pm on February 28, 2022: member

re foreign code: this version is very simple (likely too simple for copyright), but in the worst case is licensed under MIT the same as our code. see LLVM code here. (But the other reasons not to reintroduce glibc-back-compat still hold)

re patching the toolchain: I’m not aware of any easy patch to make GCC 7+ not require this. Maybe we could include __divmoddi4 in crti.o or something, but that feels ugly too. In theory -static-libgcc should do the job - but I don’t know what other ramifications that might have.

re bumping the minimum libc version for i686: this doesn’t involve libc, but we could presumably bump the minimum libgcc version. This would lose support for Debian stretch (supported under June), requiring Debian 10 (buster, oldstable, released 2019 July). It would lose Ubuntu xenial (supported until 2026), requiring at least bionic (released 2018). CentOS gained a new enough version with CentOS 8 (released 2019 September); we already don’t support older versions of CentOS. FWIW, I also have a device that requires Linux 2.6.32, which holds it back to glibc 2.25, but has fully updated to GCC 11 with no problems.

Dropped the glibc-back-compat commits and replaced them with one bumping the libgcc requirement enforced by symbol-check.

luke-jr force-pushed on Feb 28, 2022

fanquake commented at 10:48 am on March 16, 2022: member

Concept ~0.

Since we don’t officially provide i686-linux-gnu release binaries, I’m not sure if this is wanted for Core.

I agree. While the changes here are simpler than when first proposed, reintroducing --enable-glibc-back-compat would have been a NACK, as-is this would be the same as us re-introducing support in our build infrastructure for 32-bit windows builds. It seems odd for us to introduce a bunch of code that isn’t going to be exercised / tested (by us), to support binaries we don’t release.

hebasto commented at 10:48 am on March 22, 2022: member

Since we don’t officially provide i686-linux-gnu release binaries, I’m not sure if this is wanted for Core.

Concept ~0. Bitcoin Core does not need these changes.

Otherwise, code changes (c76ac9d57f2b3ff7aad57f7b3554de90224838e5) look correct.

fanquake commented at 10:58 am on March 22, 2022: member

Going to close this then. If you would like to provide Guix built i686-linux-gnubinaries for Knots, you can maintain these changes there.

fanquake closed this on Mar 22, 2022

fanquake referenced this in commit 053499f371 on Mar 24, 2022

dekm referenced this in commit d710d587f8 on Oct 27, 2022

DrahtBot locked this on Mar 22, 2023

Guix: Fix building for i686-linux-gnu #24448

Conflicts