< bitcoin-git>
[bitcoin] mjdietzx opened pull request #20276: test: run mempool_expiry.py even with wallet disabled (master...mempool-expiry-miniwallet) https://github.com/bitcoin/bitcoin/pull/20276
< bitcoin-git>
[bitcoin] ariard opened pull request #20277: p2p: Do not resolve orphans during IBD and extend p2p_ibd_txrelay.py coverage (master...2020-10-ibd-txrelay) https://github.com/bitcoin/bitcoin/pull/20277
< wumpus>
luke-jr: still the same as on github: add a platform specific override that changes the expectation for .plt to 'RW ' on power*
< wumpus>
it's expected so it's fine to change the script but not for all architectures
< luke-jr>
wumpus: ok
< wumpus>
I can take a look at fixing the script but not in the coming days
< wumpus>
maybe something like: - call `readelf -h <executable>`, parse out the 'Machine:' part - match that on what is returned for power64 (I don't know) -if so change the .plt* sections in the expected array to 'RW ' from 'R E'
< wumpus>
"Machine: PowerPC64"
< luke-jr>
right
< luke-jr>
probably no rush since it slipped 0.21 anyway
< wumpus>
well getting this in early for the 0.22 cycle would be good, at least it's finaly in then and not something that needs to be considered last minute every time :)
< luke-jr>
looks like fanquake insists on an answer to a question I don't have answers to, so no clue how to even proceed anyway
< fanquake>
luke-jr: which question
< luke-jr>
fanquake: why 970
< luke-jr>
the usual way to compare two archs in GCC doesn't work for PPC for some reason, so I have no idea
< fanquake>
Carls questions seemed reasonable, and it was unclear given you hadn't responded. I'm not sure no-response is the way forward. If you don't know why you're making that change, you could still respond to him.
< luke-jr>
it's not a change.. it's the first time we support ppc64 at all O.o
< fanquake>
Right. Well in any case, leaving him answer-less is just confusing. It's unclear if you missed it, forgot to respond, ignored it etc.
< luke-jr>
ok, so … I basically said the same thing (I don't know)
< fanquake>
Cool, thanks
< wumpus>
from what I've heard he's not the only one with tha question, more prople have concerns about that
< luke-jr>
I mean, the 970 was released in 2002..
< wumpus>
(I don't know the details, I'm not sure if the problem is whether the setting is too new or too old)
< wumpus>
targeting Talos seems most important
< luke-jr>
I think I originally had -mcpu=power9 for both
< luke-jr>
but someone complained that was too new
< luke-jr>
it's not like we can't change it later
< wumpus>
what do common linux distros target?
< luke-jr>
not sure; I think a few have recently dropped BE entirely
< luke-jr>
dunno why we can't just do 970 and if someone complains try changing it to whatever they need it to be :x
< luke-jr>
don't let perfect be enemy of good or whatever :P
< wumpus>
I haven't really followed it in detail (I will as soon as someone sends me a POWER9 machine :-) ), but it depends on what dongcarl's concerns really are
< wumpus>
in any case fanquake's remark is valid: you really need to respond to review comments even if you disagree with them, otherwise it's at the least unclear if you missed them
< wumpus>
I don't have any particular opinion on what chips to support here, I just like build system changes to be uncontroversial :)
< wumpus>
ofc, it's clear there's not that much gain to supporting 2002 chips, practally, even high end 2008 chips have a hard time running a validating bitcoin node
< wumpus>
I do also agree it's a decision that can be easily changed later
< wumpus>
would have to do some more research: what is the magnitude of the performance differences on a Talos between compiling for the different targets? is there more than a performance difference between compiling for power9 or 970? say, security extensions
< sipa>
luke-jr: do you have thr means to say benchmark a reindex-chainstate on a build with -mcpu=970 vs -mcpu=power9?
< sipa>
!jinx
< gribble>
Error: "jinx" is not a valid command.
< wumpus>
apparently in modern compilers you can also build without a .plt section at all with -fno-plt (no, not a serious suggestion to work around a python script issue, though I'm not quite sure what are the drawbacks)