--- Log opened Tue Jun 22 00:00:45 2021
00:35 -!- belcher_ is now known as belcher
01:04 -!- michaelfolkson [~michaelfo@138.68.143.20] has joined #bitcoin-core-builds
06:01 -!- triston [~triston@103.160.27.45] has joined #bitcoin-core-builds
06:09 -!- triston [~triston@103.160.27.45] has quit [Remote host closed the connection]
07:51 -!- gribble [~gribble@bitcoin/bot/gribble] has quit [Remote host closed the connection]
07:55 -!- gribble [~gribble@bitcoin/bot/gribble] has joined #bitcoin-core-builds
11:10 < dongcarl> sipa: You're right, the headers will likely give us much less trouble
11:11 < dongcarl> hebasto: I think we deprecated i686?
11:15 < sipa> yeah, long time ago
11:15 -!- belcher [~belcher@user/belcher] has quit [Quit: Leaving]
11:37 < laanwj> yes
11:38 < laanwj> ARM32 is the only 32-bit architecture we ship binaries for
11:40 < laanwj> dongcarl: if we could build against glibc MAX_VERSION we could drop the entire glibc version workaround stuff, so have a much-reduced chance of subtle bugs, i think it's how most projects do this
11:40 < laanwj> dongcarl: it's not *only* about headers though: the version information comes from the .so linked against
11:41 < dongcarl> laanwj: Yeah I'll experiment with building against MAX_VERSION
11:41 < dongcarl> Huh... How do other projects do this without Nix/Guix? Do they have their own builds script for glibc MAX_VERSION?
11:42 < laanwj> there was some experiment (for llvm) with "stub libraries" which are basically generated from a symbol list, but generally, just copy the right version of libc and use a linker path?
11:44 < laanwj> or have a toolchain based on the right version of libc (there are some standard ones like linux, e.g. there used to be LSB, no idea if that's still a thing)
11:46 < laanwj> ofc, building in a deterministic environment like a VM or container makes it a lot easier
11:46 < laanwj> much smaller chance of accidentally linking something wrong
11:47 < dongcarl> Yup :-)
11:52 < sipa> dongcarl: other projects have distro binaries and docker images :p
11:53 < dongcarl> XP
11:55 < laanwj> and distro agnostic packagers such as flatpak, appimage
11:57 < laanwj> for GUI that works better as it allows (some degree of) system integration, for command-line tools it's not really that useful
12:09 < laanwj> building bitcoind and bitcoin-cli fully statically using e.g. musl libc would be interesting for that, because it'd allow the binaries to run with any kind of libc, including on android
12:09 < laanwj> that in turn would be annoying for the GUI though as it's no longer possible to link, say, X, xkb and font libraries dynamically
12:51 < dongcarl> Yes I've long wanted that... I'm looking at the debian patches to glibc right now and a lot of them change the header... I'm somewhat concerned that subtle changes like that can trip us up at some point
13:19 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-builds
16:34 < hebasto> could be related -- https://gcc.gnu.org/legacy-ml/gcc-help/2015-12/msg00089.html
17:04 < hebasto> dongcarl: re " I think we deprecated i686?" -- right! just pointed at the limit of our guix build system I hit :)
17:07 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-core-builds
17:11 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
19:33 < hebasto> laanwj: MarcoFalke: luke-jr: would you be able to have a look at #20586 when you get a chance?
19:33 < gribble> https://github.com/bitcoin/bitcoin/issues/20586 | Fix Windows build with --enable-werror by hebasto · Pull Request #20586 · bitcoin/bitcoin · GitHub
22:13 < jarolrod> get `checking for Boost Process... configure: error: Boost::Process is required for external signer support, but not available!` at the configure stage when trying to cross-compile on linux for windows
22:38 < jarolrod> https://github.com/bitcoin/bitcoin/issues/22319
23:56 -!- cfields [~cfields@207.172.223.102] has quit [Read error: Connection reset by peer]
23:57 -!- cfields [~cfields@207.172.223.102] has joined #bitcoin-core-builds
--- Log closed Wed Jun 23 00:00:46 2021