< fanquake> wumpus: I did mention binary size increase in https://github.com/bitcoin/bitcoin/pull/19525#issue-449279147. Maybe time to merge #18605 heh
< gribble> https://github.com/bitcoin/bitcoin/issues/18605 | build: Link time garbage collection by fanquake · Pull Request #18605 · bitcoin/bitcoin · GitHub
< sipa> fanquake: good idea
< achow101> I would expect a non-negligible part of binary size increase from 0.20 to 0.21 would be the inclusion of sqlite
< sipa> oh!
< fanquake> wumpus / sipa: can probably block MONIMAKER365
< sipa> fanquake: done
< brianddk> Anyone happen to have a copy of bitcoin-0.1.2.rar for some history research I'm working on. Last sightings of it were in 2009 and 2010 on sourceforge. 2009: http://web.archive.org/web/20091127010808/http://sourceforge.net/projects/bitcoin/files, 2010:
< brianddk> I already have v0.1.0 and v0.1.3 : http://web.archive.org/web/20101210071124/http://sourceforge.net:80/projects/bitcoin/files/Bitcoin/ just missing v0.1.2. I realize it was recalled, and that these clients before 0.8.1 are non-functional, It's just a free time hobby..
< sipa> brianddk: due to the march 2013 bdb locks issue?
< sipa> you can work around that
< sipa> stuff before 0.2.10 is harder, as the network protocol changed
< sipa> you'll need a bridge node for those
< brianddk> I suppose, I'm just trying to learn the codebase from a historical perspective. Maybe not the best, but it seems interesting.
< brianddk> at least to me.
< brianddk> sipa, yeah, it was my impression the the 03-2013 issue required all clients to upgrade to 0.8.1, but I may be reading that wrong: http://web.archive.org/web/20130515133440/http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1
< sipa> you can manually configure higher limits
< fanquake> achow101: should have done 42 just to be completely sure
< achow101> fanquake: it was 44 or something like that. It was supposed to be 50 but I woke up before they were all done
< fanquake> CHECKS: Dict[str, List[Tuple[str, Callable[[Any], bool]]]] = {...
< fanquake> probably getting a bit heavy with the type annotations
< achow101> you might want to look into type aliases
< fanquake> I think I'll just leave these out for now. This is more a case of the type annotation being more confusing than just looking at the code
< fanquake> Will take a look at aliases though
< sipa> looks super readable compared to C++ types ;)
< gwillen> you can also change more things to Any if you want to make it more concise (at the expense of precision), but I also find it fairly readable :-)
< bitcoin-git> [bitcoin] fanquake opened pull request #20451: lint: run mypy over contrib/devtools (master...contrib_devtools_mypy) https://github.com/bitcoin/bitcoin/pull/20451
< luke-jr> sipa: higher limits won't enforce the softforked lower lock limit, though
< luke-jr> so for 3 months (March-May), upgrading to 0.8.1 *was* necessary for full node security
< luke-jr> well, or a backport I guess
< luke-jr> (not sure if we had a backport)
< sipa> luke-jr: that's true
< sipa> though if you just wanted it to just sync with the full chain, only validating the rules that existed at the time, it's possible
< fanquake> wumpus: re binary size. You are correct that they have grown, some quite significantly: https://github.com/bitcoin/bitcoin/pull/18605#issuecomment-731696286. I re-run some builds for 18605.
< bitcoin-git> [bitcoin] fanquake pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/816132e6eb23...e9a1c9fbdea9
< bitcoin-git> bitcoin/master 49473ef fanquake: build: convert "echo" usage into a patch in qt package
< bitcoin-git> bitcoin/master fdde4c7 fanquake: build: pass XCODE_VERSION through to qt macOS cross compile conf
< bitcoin-git> bitcoin/master bfd7e33 fanquake: build: remove plugin_no_soname from mac qt qmake.conf
< bitcoin-git> [bitcoin] fanquake merged pull request #19867: build: document and cleanup Qt hacks (master...document_remaining_sed) https://github.com/bitcoin/bitcoin/pull/19867
< wumpus> fanquake: you'd expect a slight size increase from separate sections, just not that extreme as it is for that specific architecture/compiler combo
< wumpus> fanquake: as for the type signatures you can assign names to parts, (like, = can be used as "typedef") this can make them more readable for complex ones
< sipa> wumpus: did you see achow101's comment that it could be due to sqlite?
< wumpus> also good for re-use
< wumpus> sipa: there's definitely some of the increase due to sqlite, but that would be seen on all architectures and compilers
< sipa> ah fair
< wumpus> and would not have an effect on bitcoin-cli!
< sipa> hopefully.
< wumpus> the size increase I noticed stuffs the binary with zeroes, it would be easy to measure :)
< sipa> ok
< sipa> it's really bizarre to me that whole bunches of zeroes end up in the binary
< sipa> is this really intended behavior you think?
< wumpus> the "hello world" test I mentioned went from 8kB to 4MB, the rest is just zeroes
< wumpus> no, I don't think it's intended behvior it was fixed in gcc 9
< wumpus> they exagerrated the alignment
< sipa> ah ok!
< wumpus> another thing on the list of reasons to upgrade the compiler, but then again, newer gcc might have the memcmp issue so blindly upgrading isn't a good idea
< sipa> looks like that will be fixed in the next 10.x release
< sipa> so 10.3 i guess
< wumpus> I noticed because I created a lxc environment with bionic, installed all the (ELF) cross compilers gitian does as well as the x86_64 one, then used a script that compiles the same source file for all architectures in parallel :-) The ppc64 binaries also stand out in size (with and without separate sections) but it's much less pronounced.
< wumpus> (but also due to padding)
< wumpus> not sure what the page size is of ppc64 it may be needed there
< wumpus> 64k. okay.
< bitcoin-git> [bitcoin] practicalswift opened pull request #20452: Replace use of locale dependent atoi(…) with locale-independent std::from_chars(…) (C++17) (master...remove-atoi) https://github.com/bitcoin/bitcoin/pull/20452
< wumpus> wait, C++ added a truly locale independent integer parser ? this is above any expectations for me
< wumpus> bracing myself for any subtleties that come up for reasons to avoid std::from_chars anyhow
< wumpus> it handles embedded \x00 as any other trailing garbage that's refreshing
< wumpus> and out-of-range values for the provided result type return an error
< wumpus> leading zeros are simply ignored, no octal or other unexpected base switching
< wumpus> very good
< hebasto> is it possible to observe different hashes for gitian macos builds on the same machine (made some builds in a row with the same hash)?
< hebasto> ^ yes, now I have different hashes.
< gwillen> hebasto: hmm, obviously this is not how gitian is supposed to work
< gwillen> I know very little about gitian but I know things about macs (regrettably), let me know if I can help
< hebasto> gwillen: thanks. I was curious about testing #20436, #20440 and #20447
< gribble> https://github.com/bitcoin/bitcoin/issues/20436 | depends: Add a nasty qt hack to work around clang non-determinism by theuni · Pull Request #20436 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20440 | build: fix determinism issue when building qt with Clang 8 by fanquake · Pull Request #20440 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20447 | depends: Patch qt_intersect_spans to avoid non-deterministic behavior in LLVM 8 by achow101 · Pull Request #20447 · bitcoin/bitcoin · GitHub
< sipa> gwillen: TL;DR: LLVM 8 has inherent nondeterminism in the compiler, there are various ways around it
< gwillen> ahhhh :-(
< gwillen> that is deeply regrettable and I'm surprised they did that
< sipa> gwillen: it's not too long ago that compiler determinism was unheard of entirely
< gwillen> sure, but regressing it now that a lot of people depend on it seems rude.
< luke-jr> sipa: not true
< luke-jr> sipa: there was a lot of deterministic work in the 80s
< luke-jr> forgotten by the subsequent generation
< luke-jr> (which is probably why reviving it was relatively easy?)
< sipa> gwillen: it was fixed in LLVM9, so i think it was unintentional
< bitcoin-git> [bitcoin] hebasto opened pull request #20454: build: Bump clang version to fix non-determinism (master...201122-clang) https://github.com/bitcoin/bitcoin/pull/20454