<bitcoin-git>
bitcoin/master 8e3c266 laanwj: Merge bitcoin/bitcoin#24077: util: Make base_uint::GetHex() and base_uint:...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<bitcoin-git>
bitcoin/master a4f4f89 Samer Afach: Replace uint256 specific implementations of base_uint::GetHex() and base_u...
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] laanwj merged pull request #24077: util: Make base_uint::GetHex() and base_uint::SetHex() not depend on uint256 (master...fix/arith_uint256-specializations) https://github.com/bitcoin/bitcoin/pull/24077
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<fanquake>
Agree. I'm glad we are fleshing these out though.
<fanquake>
I think it's nicer to be working from vanilla GCC + patches we know we actually need, vs distro GCC + many more / unrelated patches that no one can remember if/why they are still required.
<dergoegge>
sipa: could you chime in on #24835 ? (trying to revert one of your old (2012) commits)
<dergoegge>
It would be great if you could explain what the original motivation for the commit was
<laanwj>
fanquake: yes, agree, it's good to know what exactly was used for building
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Kaizen_K_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
<fanquake>
luke-jr: no more background to 24722 than what's in the PR description. I assume it would also effect the 23.x branch, but also only in the situation where you were using lld, or the no-longer-override-user-flags-patch
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Ping timeout: 250 seconds]
vysn has quit [Ping timeout: 260 seconds]
shesek__ has quit [Remote host closed the connection]
shesek__ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
shesek__ has quit [Remote host closed the connection]
shesek__ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<dongcarl>
Those who are following the libbitcoinkernel PRs (#24322 specifically): I've spent too much time trying to get libtool to make the right mingw-w64 dll's and it's holding up the rest of the libbitcoinkernel work. What I'm going to do is just leave it as a static library for now, so that we can make progress on the main thrust of the project (even
<dongcarl>
with just the static library, we will surface re-couplings via linker errors), open an issue detailing my spelunking, and work on getting the build correct in the mean time.
<laanwj>
dongcarl: sgtm
<laanwj>
one step at a time
<dongcarl>
laanwj: I definitely underestimated how complicated the unholy combination of libtool+mingw-w64+dll's+libwinpthread can be 😅
<laanwj>
solving the dynamic library issue for windows is probably going to be challenging, can imagine that's not really what you'd prefer to spend time on right now, we could skip windows as a platform for lbitcoin kernel initially
<dongcarl>
Huh... Yeah that would work too!
<laanwj>
someone that knows and cares about windows could help get it working later
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
<dongcarl>
👍
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
jarthur_ is now known as jarthur
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
shesek__ has quit [Remote host closed the connection]
<laanwj>
we did a similar thing for libbitcoin_consensus from what i remember, building a dll w/ mingw was an extra challenge
<laanwj>
and this is quite the bit more complex
<laanwj>
also C++ dynamic libraries are annoying on windows anyway because the C++ ABI differs between MSVC and mingw, at least this used to be the case i don't know about nowadays
<dongcarl>
Yeah I saw the `archive_cmd_CXX` override we do, and realized that we definitely ran into this problem once before, but now with the extra challenge of winpthread being thrown in the mix
<laanwj>
it's fine to want to avoid that problem for now it's just a ton of little platform specific technical details and irrelevant to bitcoin_kernel API design
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<dongcarl>
Yup... Well... got a lot of untangling to do before we even get to the API design part...
* dongcarl
is still looking for someone to help with the API design part b/c he has not experience.
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] achow101 opened pull request #24855: rpc: Fix `setwalletflag` disabling of flags (master...fix-setwalletflag-disabling) https://github.com/bitcoin/bitcoin/pull/24855
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jonatack has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
<_aj_>
dongcarl: yay for running away and hiding from libtool, it's the only sensible decision
<laanwj>
looks like no meetings topics have been proposed in advanced using #proposedmeetingtopic this week
<laanwj>
any last minute ones?
<fanquake>
Just Guix build the recently-tagged rc5
<sipa>
done, will attest
jonatack has quit [Ping timeout: 256 seconds]
<laanwj>
ah yes, we tagged rc5, if you run windows it makes sense to upgrade to it, it will solve crashes (there's a known one in the bandwidth tab of the debug window, but this issue likely caused more problems), there are no changes since rc4 for other platforms
<luke-jr>
on that, I didn't read how it got fixed yet, but I did see a few KDE patches for Qt that _might_ be relevant IIRC
<fanquake>
given it was fixed by patching GCC, I don't think they'll be relevant
<laanwj>
SEH (stack unwinding) was effectively broken, we ported a patch for gcc that solves it
<luke-jr>
ah
<luke-jr>
kinda disturbing how often GCC has bugs like this :x
<laanwj>
yes, windows is a lowest-prio-tier target for them
<sipa>
It certainly seems mingw has far more issues than gcc for mainline platforms.
<luke-jr>
well, even mainline, there's stuff like the memcmp thing too
<hebasto>
maybe clang will better work for windows
<luke-jr>
(which IIRC they *still* haven't fixed for GCC 9)
<laanwj>
definitely; gcc bugs tend to be rare otherwise, and if they happen really obscure
<laanwj>
something like breaking longjmp would never make it far in linux
<luke-jr>
hebasto: do many people use Clang for Windows targets?
<hebasto>
idk
<laanwj>
at least rust uses clang for windows, from what i've heard it works pretty well but have no experience myself