<cfields>
ryanofsky: yeeesh, I didn't realize that CMake has _no concept_ of build-side tools during cross-compile :\
<cfields>
that's... crazy. And makes this messy :(
preimage has quit [Ping timeout: 252 seconds]
<ryanofsky>
i'm actually very happen with the current solution, there is basically very little change to anything. i was expecting it to be much messier
<cfields>
ok, I'll reserve judgement. It just didn't look anything like I expected because I wasn't aware of that.
preimage has joined #bitcoin-core-dev
<cfields>
right, yeah, I was just reading up on that approach.
<hebasto>
cfields: qt resolved a similar problem by requiring to have a native qt installed before cross building
<cfields>
hebasto: right, in the case of depends it makes sense to split them up and have them hard-coded because those steps are automated. This one unfortunately is user-facing.
<cfields>
ryanofsky: thanks for the pr. I haven't really experimented with building this stuff that much, just once a long time ago. So I'm catching myself up now on how it all works together.
<ryanofsky>
of course, and let me know if you run into any snags. I can probably help and also explain anything the build is doing since build system code is not the most readable
<fanquake>
I think ideally we won’t end up with just having a 3rd different (supported) way to use multiprocess. Which would seem to be the case with this PR. Will have to look at the details tomorrow though
<cfields>
no worries, i'll try to figure it out myself first. may take a while, but that'll force me to understand it :)
<cfields>
right, agreed.
<cfields>
ok, but tldr the high-level hack is that depends is using our own source-tree has a "package", right?
zeropoint has joined #bitcoin-core-dev
<ryanofsky>
yes, i don't see it as a hack, i think it useful to be able to use a local directory as a package and it was pretty trivial to implement
<cfields>
nm, I see the comment now.
<ryanofsky>
it is respecting build ids and everything so if directory contents change downstream dependencies are rebuilt
<cfields>
ack
ghost43 has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 264 seconds]
SpellChecker has joined #bitcoin-core-dev
ghost43_ has quit [Ping timeout: 264 seconds]
Guest57 has joined #bitcoin-core-dev
Guest57 has quit [Quit: Client closed]
<cfields>
ryanofsky: are the generated source files platform-specific, or could they (in theory) be committed to the repo?
<ryanofsky>
no, they are not platform specific, and you can see them by building with -DBUILD_MULTIPROCESS=ON and running find -name '*.capnp.*'
<cfields>
hmm, I wonder if committing them would be a more reasonable approach, then? With a build target for generating them locally, same as we do for (for ex) qt translations.
<cfields>
I assume we won't be updating them that frequently?
jespada has joined #bitcoin-core-dev
<ryanofsky>
during development they are updated every time you add a method or struct field, method parameter etc. it is definitely convenient to just update the source and just run make
Talkless has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<sipa>
i'm trying to add a new binary (just for experimentation, not something that ever needs to be PR'ed), i copied the {,src/}CMakeLists.txt logic for bitcoin-tx, and a new binary gets built which runs, but when i try to invoke any random.h function, i get this error:
<sipa>
/usr/bin/ld: util/libbitcoin_util.a(clientversion.cpp.o): in function `std::_Function_base::_M_empty() const':
<sipa>
/usr/include/c++/14/bits/std_function.h:247:(.text+0x12a8): undefined reference to `G_TRANSLATION_FUN[abi:cxx11]'
<sipa>
/usr/bin/ld: /usr/include/c++/14/bits/std_function.h:247:(.text+0x1db5): undefined reference to `G_TRANSLATION_FUN[abi:cxx11]'
<sipa>
anyone have a clue?
<bitcoin-git>
[bitcoin] jurraca opened pull request #31742: contrib: fix BUILDDIR in gen-bitcoin-conf script and gen-manpages.py (master...fix-builddir) https://github.com/bitcoin/bitcoin/pull/31742
<glozow>
sipa instagibbs i got about halfway implementing what you described (currently running fuzzer on my helper funcs). I was trying to break it this weekend and couldn’t come up with anything. (eg if peers can work together to exceed limits or keep things in orphanage forever. or if it’s possible to get into a state where we can’t find anything to evict which is where i got stuck last time I tried to make eviction smarter)
<ryanofsky>
sipa, you need to add `#include <util/translation.h>` and `const TranslateFn G_TRANSLATION_FUN{nullptr};`
<ryanofsky>
rn any executable which uses libbitcoin_util needs these
<glozow>
^just a progress report, i promise i’m working on it!
<sipa>
ryanofsky: oh, i totally missed that G_TRANSLATION_FUN could be something in our codebase, it sounded like a strange linker magic thing
<sipa>
thank you!
<sipa>
glozow: cool!
<instagibbs>
cool! I think I've convinced myself, assuming pretty reasonable assumptions, we won't do "any worse" vs today.
<instagibbs>
Precluding the scenarios where people are doing a lot of beefy CPFPing children in a short window for whatever reason
Guest27 has joined #bitcoin-core-dev
<sipa>
an observation that sdaftuar which i didn't consider: generally "orphan packages" over 400 kWU will fail to reconstruct just to ancestor/descendant vsize limits in the mempool
<instagibbs>
you're left with 4kwu after that, so it would be a weird package for sure
<sipa>
ok, or set the reservation tot 404 kWU i guess
<sipa>
but the point is that ~400 kWU reservation per peer should be enough, as long as there is just a single orphan package in flight at a time from any given peer
Guest27 has quit [Ping timeout: 240 seconds]
<instagibbs>
if the reservation was 4MWU that is ~10 max weight txns, and thus packages. If the "average case" orphan is 40kWU instead, that would put us at ~100. I think that's likely an overshoot of the actual average.
<sipa>
indeed
<sipa>
I still think a higher reservation for outbounds is acceptable (~4 WMU)
<glozow>
yeah I think doing 400kwu per peer was what we were thinking, but we had been saying 10x that for outbounds
<glozow>
are we thinking we don’t need to give outbounds extra?
<sipa>
glozow: i guess my thinking is "we don't need to give outbounds (as much) extra, but we can, so why not?
<instagibbs>
im thinking extra like sipa says, to be clear, I just don't want to do worse if all outbounds are relatively in sync
<glozow>
right
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<glozow>
we could brainstorm a “popular orphan” score for automatic protection or lower likelihood of eviction maybe? but future work
<glozow>
(to mitigate the “outbounds in sync” thing)
<instagibbs>
yeah we can complicate things later...
<instagibbs>
"do no harm" was my only concern for now
<sipa>
glozow: the "evict one announcer among those whose usage/reservation ratio is maximal" idea will sort of naturally mean that things announced by many peers don't actually get evicted easily
<sipa>
(with high probability)
<instagibbs>
IIRC your idea means nothing would be dropped in non-attack/unusual load scenarios
<sipa>
but it doesn't take within-peers relations into account (like one parent orphan with many child orphans... terminology is confusing, how can orphans have parents?)
<sipa>
anyway, i don't think any of this is all that important short-term
bytes1440000 has joined #bitcoin-core-dev
<bytes1440000>
Banning me wont work. I don't need to explain it. Please get better at your job that you are so arrogant about. Last Pull request that got CVE in 2018 was also reviewed by sipa so..