--- Log opened Thu Mar 04 00:00:46 2021
00:28 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio] has joined #bitcoin-builds
00:29 -!- jarolrod_ [sid475272@gateway/web/irccloud.com/x-xgqmsomclcrfgckc] has joined #bitcoin-builds
00:29 -!- michaelfolkson2 [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined #bitcoin-builds
00:29 -!- glozow_ [sid453516@gateway/web/irccloud.com/x-halahfbtacapjfun] has joined #bitcoin-builds
00:31 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-builds
00:32 -!- TheCharlatan [~drgrid@2a01:4f9:4a:2adc::2] has joined #bitcoin-builds
00:43 -!- Netsplit *.net <-> *.split quits: glozow, TheCharl1, jarolrod, michaelfolkson, ajonas, achow101
00:43 -!- glozow_ is now known as glozow
01:18 < elichai2> How do we handle glibc versions?(in dynamic linking) by compiling on old enough dist so that all our users will have newer glibc's?
01:18 < fanquake> We compile releases using focal (2.31). Minimum required is  2.17. don
01:19 < fanquake> *so we don't use any symbols newer than that.
01:19 < fanquake> There's also still some glibc back-compat code that I've been meaning to remove.
01:20 < fanquake> this is checked in symbol-check.py
01:25 < elichai2> fanquake: so we manually check for symbols to make sure there aren't any symbols that require higher than 2.17?
01:26 < elichai2> I would think gcc/clang might generate newer symbols on a whim if they see they're available? but I probably don't understand glibc dynamic linking and symbols well
01:26 < fanquake> yes https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/symbol-check.py#L155
01:30 < elichai2> So the compilers currently play nice and we just need to verify that, that's nice
01:44 < elichai2> fanquake: when I'm compiling on my machine I get dozens of newer symbols(I see both in readelf and symbol-check), is there any way to prevent that if I want to compile something on my machine and move the binary to an older one?
01:46 < fanquake> You essentially want to emulate what we do when we build releases. Start by passing --enable-glibc-back-compat to ./configure
01:46 < fanquake> https://github.com/bitcoin/bitcoin/blob/92b7efcf54d3154e4b31c9a6eae60f27e349f45e/contrib/gitian-descriptors/gitian-linux.yml#L50
01:52 < elichai2> That didn't help by a lot but I guess i'll go over the build process there and try to do the same
01:52 < elichai2> Thanks!
02:16 < wumpus> our current approach works fine though i think in the long run it would be nice to move to musl libc and fully static linking https://github.com/bitcoin/bitcoin/issues/18110
02:49 < elichai2> wumpus: I wonder how will musl affect performance
02:57 -!- belcher_ is now known as belcher
03:17 -!- michaelfolkson2 is now known as michaelfolkson
04:18 -!- Maximillia41Wiso [~Maximilli@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-builds
04:25 < wumpus> elichai2: me too !
04:26 < wumpus> it's one of the open questions in that PR
04:27 < wumpus> my gut feeling is that it will not or hardly make a difference for e.g. chain sync time, we're not really performance bound at either system call (which could be faster with static linking) or memory allocations (which could be slower with musl libc) level, but it would be neat to see measurements
04:49 < elichai2> I do remember `new/delete` pretty high in some performance tests I ran 2 years ago, but I don't remember if it was in IBD and if it was with assumevalid or without
04:58 < wumpus> leveldb does a bit of it while building batches
05:00 < wumpus> that said if musl libc's allocator turns out to be problematic we could link something like jmealloc which is faster than a lot of OS'es native allocator in many circumstances
05:00 < wumpus> it wouldn't really be reason to abandon the idea completely
06:03 -!- jonatack_ [~jon@37.173.203.38] has joined #bitcoin-builds
06:09 -!- jonatack_ [~jon@37.173.203.38] has quit [Quit: jonatack_]
06:38 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #bitcoin-builds
06:39 < elichai2> I wanted to benchmark bitcoin core with a thread local allocator like tcmalloc at some point
06:52 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 256 seconds]
06:55 -!- jonatack [~jon@37.173.203.38] has joined #bitcoin-builds
07:53 -!- emzy [~quassel@2a01:4f8:192:628a::83] has quit [Changing host]
07:53 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-builds
07:54 < wumpus> are the built depends libraries cached anywhere for guix? i think it rebuilds qt every time here (and I do take care to not clear BASE_CACHE and other precious directories)
08:01 < wumpus> guix builds seem to take really long in general
09:35 -!- Maximillia41Wiso [~Maximilli@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 264 seconds]
10:20 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio] has quit []
10:21 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vbqmiwqebvrkdcvc] has joined #bitcoin-builds
10:36 -!- achow101_ is now known as achow101
11:01 -!- jonasschnelli_ is now known as jonasschnelli
12:37 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-builds
12:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
12:41 -!- lukedashjr is now known as luke-jr
12:42 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
12:44 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-builds
12:55 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in]
12:55 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #bitcoin-builds
13:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-builds
13:08 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
13:09 -!- belcher_ is now known as belcher
15:03 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 256 seconds]
15:15 -!- jonatack [~jon@37.173.203.38] has joined #bitcoin-builds
15:56 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 260 seconds]
15:59 -!- jonatack [~jon@37.173.203.38] has joined #bitcoin-builds
16:44 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
16:53 -!- jonatack_ [~jon@37.171.225.50] has joined #bitcoin-builds
16:54 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-builds
16:56 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 264 seconds]
17:04 -!- jonatack_ [~jon@37.171.225.50] has quit [Ping timeout: 246 seconds]
17:05 -!- jonatack_ [~jon@37.172.247.108] has joined #bitcoin-builds
17:08 -!- jonatack_ [~jon@37.172.247.108] has quit [Read error: Connection reset by peer]
20:48 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
21:05 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-builds
--- Log closed Fri Mar 05 00:00:47 2021