< gwillen>
it;s weird, it's passing through -fstack-protector-all
< gwillen>
even though it does not appear to be documented to do that
< sipa>
i assume that they're just using a libtool that's sufficiently old to not know about asan
< wumpus>
nah I have similar experiences with libtool on other platforms just for different things, it has a really bizarre filter
< sipa>
wait
< sipa>
that patch linked that fixes it in libtool upstream is dated july 24th 2018
< gwillen>
I'm on a mac, my libtool may never be updated
< gwillen>
it's probably fixed for other people :-)
< gmaxwell>
sipa: that doesn't make much sense, since it's worked elsewhere for forever.
< sipa>
gwillen: i assume that our depends environment builds libtool from scratch'
< gmaxwell>
(possible everywhere was just patching libtool and we don't)
< wumpus>
gwillen: yes I'm sure a newer libtool will fix this
< wumpus>
they only let through compile options they know about for some strange reason
< gwillen>
let's see if homebrew has libtool, that can't possibly go wrong
< sipa>
gmaxwell: nvm, i'm stupid and looking at the wrong commit
< wumpus>
which would be okay, I guess, if they warned instead of silently ignoring
< sipa>
wumpus: i guess they want to filter what goes to linker, what to compiler, what to other things, ...?
< sipa>
and sometimes guess wrong?
< sipa>
not knowing it has to go to multiple of them
< wumpus>
sipa: it's gcc that does that
< sipa>
right
< sipa>
i guess i am clueless about libtool
< wumpus>
and gcc is very strict in argument parsing
< wumpus>
me too, mostly
< wumpus>
it's one of those things you'd wish wasn't necessary in the first place
< gwillen>
hm, that's odd, it seems like I am supposed to be using latest libtool, although it's kind of hard to tell
< gwillen>
I guess I don't understand the relationship between the libtool script and the libtool installed on the system
< gwillen>
but the libtool script was generated with libtool 2.4.6 which is latest
< gwillen>
I can't tell whether the system's libtool is something it invokes, or only something that would be used to generate it
< wumpus>
it's... complicated
< gwillen>
heh.
< gwillen>
I hate build systems.
< wumpus>
I think it's autoconf that generatesthe libtool executable from m3 templates elsewhere
< wumpus>
m4*
< wumpus>
I think that's libtool*ize*
< sipa>
i never realize those could be distinct things
< wumpus>
gwillen: I don't think I hate it, it's useful, but also it's grown organically to such a monstriosity
< gwillen>
*nods*
< wumpus>
in any case if the generated libtool executable that you have is sufficiently new I think that means everything should be okay
< gwillen>
and yet it fails :-(
< wumpus>
yep ...
< gwillen>
it seems there is a magic flag to tell libtool to fuck off: "-XCClinker"
< gwillen>
means "pass the following flag directly to cc when linking"
< gwillen>
also the joke is apparently on me because all this was to build libbitcoinconsensus which nothing is actually using (?), apparently it had already built bitcoind the whole time I was fighting with this :D
< wumpus>
yes, libconsensus is a library meant for external usage
< wumpus>
it still shouldn't fail the build I suppose
< bitcoin-git>
[bitcoin] gwillen opened pull request #14588: Refactor PSBT signing logic to enforce invariant and fix signing bug (master...feature-psbt-sign-fix) https://github.com/bitcoin/bitcoin/pull/14588
< * luke-jr>
wonders why there are nodes claiming to be 0.17.0.15
< fanquake>
re 0.17.0.1, there are now 3 unsigned gitian sigs for win/linux, 4 for macOS
< wumpus>
fanquake: thanks for reminding me will push mine
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
< bitcoin-git>
bitcoin/master fa78a2f MarcoFalke: [tests] Test that nodes respond to getdata with notfound...
< bitcoin-git>
bitcoin/master c70f9c0 MarcoFalke: Merge #14571: [tests] Test that nodes respond to getdata with notfound...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14571: [tests] Test that nodes respond to getdata with notfound (master...Mf1810-qaNotfound) https://github.com/bitcoin/bitcoin/pull/14571
< bitcoin-git>
bitcoin/master fa511e8 MarcoFalke: Pass tx pool reference into CheckSequenceLocks
< bitcoin-git>
bitcoin/master efaf2d8 MarcoFalke: Merge #13783: validation: Pass tx pool reference into CheckSequenceLocks...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13783: validation: Pass tx pool reference into CheckSequenceLocks (master...Mf1807-txPoolValidation) https://github.com/bitcoin/bitcoin/pull/13783
< midnightmagic>
but it looks ugly
< midnightmagic>
er. sorry wrong channel
< bitcoin-git>
[bitcoin] harding opened pull request #14589: Docs/Release notes: 0.17.0.1 is a minor release (0.17...2018-10-rn-minor) https://github.com/bitcoin/bitcoin/pull/14589
< phantomcircuit>
gmaxwell, i think the only way to avoid confusion about what's happening is to visualize the block download window
< phantomcircuit>
but that's a significant amount of effort
< phantomcircuit>
(or at least i think it is, what do i know about qt)
< gmaxwell>
I don't think confusion about the download window is a frequent problem?