--- Log opened Thu Mar 18 00:00:59 2021 00:44 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has quit [Read error: Connection reset by peer] 00:46 -!- mol [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-builds 02:02 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has quit [Ping timeout: 264 seconds] 02:02 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined #bitcoin-builds 02:02 -!- Topic for #bitcoin-builds: Bitcoin Core build system discussions | Channel logs: http://gnusha.org/bitcoin-builds/ | To get started learning about our build system: https://github.com/bitcoin/bitcoin/tree/master/depends 02:02 -!- Topic set by dongcarl [sid321684@gateway/web/irccloud.com/x-wqiqtyqzfcknbffs] [Wed Jun 12 07:21:12 2019] 02:02 [Users #bitcoin-builds] 02:02 [ _0x0ff ] [ jarolrod_ ] 02:02 [ achow101 ] [ jb55 ] 02:02 [ ajonas ] [ jonasschnelli ] 02:02 [ aqua42 ] [ kanzure ] 02:02 [ belcher_ ] [ kcalvinalvin ] 02:02 [ cfields ] [ luke-jr ] 02:02 [ copumpkin ] [ MarcoFalke ] 02:02 [ ctrlbreak_MAD] [ meshcollider ] 02:02 [ dergoegge ] [ michaelfolkson] 02:02 [ digi_james ] [ midnight ] 02:02 [ dongcarl ] [ mmitech___ ] 02:02 [ dr-orlovsky ] [ mol ] 02:02 [ elichai2 ] [ nckx ] 02:02 [ emzy ] [ nothingmuch ] 02:02 [ fanquake ] [ phantomcircuit] 02:02 [ felixweis ] [ robert_spigler] 02:02 [ fjahr ] [ robot-dreams ] 02:02 [ Galvas ] [ ryanofsky_ ] 02:02 [ ghost43_ ] [ sipa ] 02:02 [ glozow ] [ TheCharlatan ] 02:02 [ gnusha ] [ thrasher`_ ] 02:02 [ gribble ] [ tylerchambers ] 02:02 [ harding ] [ unauvum ] 02:02 [ hebasto ] [ willcl_ark ] 02:02 [ Jackielove4u ] [ wumpus ] 02:02 [ jakesyl ] 02:02 -!- Irssi: #bitcoin-builds: Total of 51 nicks [0 ops, 0 halfops, 0 voices, 51 normal] 02:02 -!- Channel #bitcoin-builds created Mon May 20 09:25:34 2019 02:04 -!- Irssi: Join to #bitcoin-builds was synced in 124 secs 05:26 -!- belcher_ is now known as belcher 07:46 -!- jonatack [~jon@37.164.254.128] has joined #bitcoin-builds 10:04 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.165.130] has joined #bitcoin-builds 10:07 -!- ctrlbreak_MAD [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 264 seconds] 12:10 -!- willcl_ark [~quassel@unaffiliated/willcl-ark/x-8282106] has quit [Remote host closed the connection] 12:12 -!- willcl_ark [~quassel@unaffiliated/willcl-ark/x-8282106] has joined #bitcoin-builds 12:48 < dongcarl> wumpus: Shot in the dark: would you happen to know if RPATH fiddling/patching would affect the size of `.dynstr`? 12:51 -!- jonatack_ [~jon@37.173.214.42] has joined #bitcoin-builds 12:52 -!- jonatack [~jon@37.164.254.128] has quit [Ping timeout: 245 seconds] 12:56 < wumpus> dongcarl: yes i think it would; DT_RPATH refers to a dynstr string entry IIRc 12:58 < wumpus> (and same for DT_RUNPATH which seems to be the newer convention) 12:58 < dongcarl> Oh fantastic! I think I know what's causing our non-determinism now :-) 12:59 < dongcarl> hebasto: I realize you mean the one between you and jarolrod_, I haven't looked into that one yet 12:59 < dongcarl> But at least the unsigned tarball one I know a fix for 13:00 < dongcarl> While I have you here hebasto, wumpus: I think it makes more sense to build native tools that end up in unsigned.tar.gz as static binaries if they don't use NSS, right? 13:01 < dongcarl> I think the rule of thumb should be: if a binary ends up in the output, it should be as portable as possible. 13:01 < dongcarl> - For the bitcoin binaries, it means passing the symbol check 13:01 < dongcarl> - For binaries in *-unsigned.tar.gz, as long as they don’t depend on NSS, they can actually be static 13:02 < wumpus> sounds good to me glibc static is fine if we don't ship them and they don't use network code 13:02 < wumpus> for anything else we'd really want to move to musl libc 13:03 < hebasto> just a few hours ago fanquake and me have a similar discussion 13:04 < dongcarl> Haha great 13:04 < hebasto> he points that it is better to have runtime dependencies on system's packages as they are well supported 13:04 < dongcarl> hebasto: Oh I'm just talking about the native tools 13:05 < hebasto> ah, ok 13:05 < dongcarl> Like `dmg`, which gets run in the codesigning container 13:05 < dongcarl> I feel like whenever we're "transporting binaries" they should be built as portably as possible 13:05 < hebasto> makes sense for me 13:06 < wumpus> i prefer the determinism of static linking nowadays, for distributed binaries, less moving parts and only a dependency on the kernel, i had too much dll/so hell in my time 13:06 < dongcarl> hebasto: Cool, I'm going to get back to you on the repro stuff! 13:07 < wumpus> dynamic linking is great for things that are built as part of the OS itself, but not for foreign objects 13:08 < hebasto> we were talking on Qt dependencies, e.g., libxkbcommon-x11 13:08 < hebasto> in context of https://bitcoinbuilds.org/?job=d9c12eae-f285-4a2f-84f1-0146da9c659d 13:09 < dongcarl> wumpus: I fully agree. Guix has a somewhat interesting solution to this: when distributing to unknown distros, use `guix pack`, which packages up a subtree of the dependency graph into a fully portable but still dynamically linked executable. 13:10 < dongcarl> dynamically linked not to the distro's version of libs, but to the libs in the tree package ofc 13:10 < dongcarl> to be clear we're not using this for our builds :-) 13:11 < hebasto> dongcarl: is it like others portable contaneirized apps? 13:12 < dongcarl> hebasto: Maybe! I haven't looked at things like AppImage and such yet 13:13 < wumpus> yes shpping portable Linux GUI software is awful, i think any static linking experiments should focus on bitcoind and the cli tools first 13:14 < dongcarl> hebasto: I think `guix pack` is more easily reproducible, but that could change: https://github.com/AppImage/AppImageKit/issues/929 13:14 < wumpus> Qt relies on dynamic linking for some things IIRC it is a much more thorny issue 13:15 < hebasto> and it, Qt, increases the list of runtime deps from version to version 13:15 < dongcarl> Agreed, I've been bitten by Qt's build system too many times... I avoid messing with it as much as I can... 13:17 < wumpus> but for daemons and command line utilities it's pretty much a no-brainer nowadays, much better to not have to rely on a specific system libc 13:17 < wumpus> (more so for embedded platforms) 16:10 -!- jonatack_ [~jon@37.173.214.42] has quit [Ping timeout: 240 seconds] 16:47 < fanquake> Just to clarify here, my comments above are only in regards to qt 16:49 < fanquake> I have no interest in increasing the scope of runtime dependencies for anything else, and that's certainly not what I said. 16:50 < fanquake> I have also been meaning to try look at doing something for #18110 for a while now 16:50 < gribble> https://github.com/bitcoin/bitcoin/issues/18110 | build: Explore building with musl as libc · Issue #18110 · bitcoin/bitcoin · GitHub 17:11 < sipa> how to figure out which symbol is bringing in GLIBC_2.29 as requirement? 17:19 < sipa> pow, exp, log from libm 17:20 < fanquake> and fcntl64 17:20 < sipa> and fcntl64 17:20 < sipa> indeed 17:26 < fanquake> also need to either fix or update our symbol checks 17:26 < sipa> bionic is only from 2018, i think we don't want to drop support for *running* on that 17:28 < fanquake> definitely not. I mean our symbol check script should be failing if the binary contains symbols that are too new 17:28 < sipa> right 17:28 < fanquake> The "oldest" symbol is should have, is clock_gettime from glibc 2.17 17:51 < fanquake> Looks like there could be an issue in Pixie where it is returning None where it should be returning symbol version numbers 20:35 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-builds 20:38 -!- mol [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 264 seconds] 21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-builds 21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] --- Log closed Fri Mar 19 00:00:00 2021