< luke-jr> wumpus: poke, can you build v0.14.2-uasfsegwit1.0?
< phantomcircuit> there's functional tests that seem to randomly fail
< kanzure> is there a trick to getting the test framework to let node[3].generate(10) actually cause additions to listunspent output
< sipa> kanzure: maturity is a bitch
< sipa> you need mine 100 more blocks first
< kanzure> but 105 didn't work either.
< kanzure> oh.
< bitcoin-git> [bitcoin] ReneNyffenegger closed pull request #10768: Build System: Prevent warning about "maybe uninitialized variable" nStart in init.cpp (master...init-nStart) https://github.com/bitcoin/bitcoin/pull/10768
< jtimon> what is src/wallet.backup ? and what is making my unittests fail?
< wumpus> luke-jr: sure
< gmaxwell> I'd seen an shorter version of this presentation before (and I think linked it here), on failures in fault tolerant systems... some good nightmare fuel (it's on HN right now) https://c3.nasa.gov/dashlink/static/media/other/ObservedFailures1.html
< luke-jr> wumpus: he's saying we should make manpages and ONLY document in those
< luke-jr> ie, get rid of the --help details and RPC help stuff
< gmaxwell> why wouldn't we just improve the --help and improve the autogen
< luke-jr> he seems to think documentation simply belongs in manpages
< luke-jr> I don't necessarily agree (nor disagree).
< gmaxwell> documentation in the system is very helpful, from a pratical perspective.
< gmaxwell> and much easier to keep updated, and acts as source code documentation too
< wumpus> no one is going to maintain external manpages, the generation is useful imo
< wumpus> I agree that creates an overlap between --help output and the man page, but I don't see it as a problem
< luke-jr> the only ways I see to improve on how we do it now are 1) we lost a manpage for bitcoin.conf, and 2) they ideally would be auto-generated during the build
< wumpus> and moving the manpages from doc/man to src makes no sense either, that directory is already cluttered enough
< bitcoin-git> [bitcoin] sipa opened pull request #10821: Add SSE 4.2 optimized SHA256 (master...20170713_shasse) https://github.com/bitcoin/bitcoin/pull/10821
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7666250ffb4e...db825d293be8
< bitcoin-git> bitcoin/master d34d77a Cory Fields: build: verify that the assembler can handle crc32 functions...
< bitcoin-git> bitcoin/master db825d2 Wladimir J. van der Laan: Merge #10806: build: verify that the assembler can handle crc32 functions...
< bitcoin-git> [bitcoin] laanwj closed pull request #10806: build: verify that the assembler can handle crc32 functions (master...configure-check-asm) https://github.com/bitcoin/bitcoin/pull/10806
< bitcoin-git> [bitcoin] jtimon opened pull request #10822: TOTEST: Also server txo from gettxout (not just utxo and mempool) (master...b15-rpc-txo) https://github.com/bitcoin/bitcoin/pull/10822
< jonasschnelli> Is there no RPC call (chain) to get a rawtx if I know height and txid?
< wumpus> jonasschnelli: #10275?
< gribble> https://github.com/bitcoin/bitcoin/issues/10275 | [rpc] Allow fetching tx directly from specified block in getrawtransaction by kallewoof · Pull Request #10275 · bitcoin/bitcoin · GitHub
< jonasschnelli> Oh! Nice... I missed that
< jonasschnelli> I even commented... :/
< jonasschnelli> Would allowing a range of blocks (defined by height) make sense as addition?
< wumpus> not sure...
< wumpus> when does that use case happen? you know a transaction is in a certain block range?
< jonasschnelli> Use case, I know a txid but don't know if it is confirmed or not... maybe you can say "check the last X blocks for txid Y"
< jonasschnelli> But yeah.. meh.
< jonasschnelli> 10275 is really nice
< sipa> wumpus: i actually said to gmaxwell earlier today about
< sipa> wumpus: i actually said to gmaxwell earlier today about 10820 "in about 3 years someone will try to compile with OpenBSD, and notice that it doesn't work... and then we'll add some #ifdefs around it"
< jonasschnelli> I tried to compile Core on a openBSD VM. But I could not even install python3. The package manager idled endless at the point of decompression...
< wumpus> sipa: hah, no need to wait for that, I compile bitcoin core on openbsd quite a lot
< wumpus> jonasschnelli: strange
< mmgen> signrawtransaction is adding the redeem script but not the witness data to transaction. Can anyone help?
< mmgen> (I'm adding segwit support to my wallet)
< mmgen> And the "signed" transaction with no witness relays OK on testnet and is included in mined block. Strange.
< mmgen> What am I missing?
< jonasschnelli> mmgen: can you maken an example and file an issue on github?
< jonasschnelli> Ideally show your process and in-/output
< mmgen> I don't think this warrants an issue. I'm clearly doing something wrong. signrawtransaction can sign segwit ps2h TXs if you supply the redeem script and keys, right?
< mmgen> The sign operation returns OK. TX broadcasts OK. TX is mined. But there's no signature.
< mmgen> jonasschnelli: testnet tx d207ffb90c4ceee2ce242990f69b91f67639f25a7b2be76c13b853a0a376b1b5
< mmgen> jonasschnelli: just mined
< mmgen> jonasschnelli: but has no signature
< arubi> mmgen, you're redeeming a p2sh of 0x17 0x160014b7bddbc682c9d41dda1e40c9e5bffcfca385af78
< arubi> you want to redeem a p2sh of "0x00 0x14 0xb7bddbc682c9d41dda1e40c9e5bffcfca385af78" where the length of that script is 0x16
< mmgen> arubi: ok
< mmgen> arubi: thanks, will check it out
< arubi> np mmgen, at least it looks like it. I don't know what you signed
< mmgen> arubi: Busy now, I'll get back to you in about 30 min
< arubi> ok, anyway the hash160 is of 160014B7BDDBC682C9D41DDA1E40C9E5BFFCFCA385AF78 instead of 0014B7BDDBC682C9D41DDA1E40C9E5BFFCFCA385AF78
< mmgen> arubi: I just need to remove the leading 0x16 i think
< mmgen> thought the 0x16 was needed for data push
< mmgen> arubi: I was creating the redeem script like this: '160014' + hash160(pubhex)
< mmgen> Strange that signrawtransaction didn't complain though
< mmgen> despite my malformed script
< arubi> it's just redeeming a p2sh of a single push of what you hash160'ed
< arubi> it's not a segwit scriptpubkey, so no sig is needed
< mmgen> but without the key it wouldn't sign for some reason
< arubi> try with a different key :)
< mmgen> arubi: will try. Thanks much for your help
< mmgen> arubi: so any p2sh script consisting of a single data push is redeemable. OP_EQUAL returns True, the stack is empty, so it's valid.
< mmgen> arubi: wonder if some sort of sanity check should be added to prevent goofups like this?
< arubi> the stack isn't empty, it has a final 0x01 on it from the TRUE executing
< mmgen> ok, True's on the stack, so it's valid
< arubi> er, from the EQUAL
< mmgen> so now if I spend to that address again, anyone who's seen the script can steal the coins
< arubi> anyway, we're getting off topic here :)
< arubi> right
< mmgen> so maybe the client should reject p2sh scripts consisting of a single data push then?
< bitcoin-git> [bitcoin] janstary closed pull request #10805: have proper manpages for bitcoin*(1) (master...master) https://github.com/bitcoin/bitcoin/pull/10805
< arubi> reject how? it can't tell what the script is when you fund the address
< mmgen> oh, right
< mmgen> just when you sign, and by then it's too late
< arubi> note you'd still be pushing a single value for redeeming a p2sh(segwit), the segwit spk itself serialized
< mmgen> so there's no real point in checking at the signing stage
< mmgen> arubi: ok
< cfields> sipa: I believe I know the problem with #10821. Testing a fix.
< gribble> https://github.com/bitcoin/bitcoin/issues/10821 | Add SSE 4.2 optimized SHA256 by sipa · Pull Request #10821 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] greenaddress opened pull request #10823: Allow all mempool txs to be replaced after a configurable timeout (default 6h) (master...replace-by-fee-old-transactions) https://github.com/bitcoin/bitcoin/pull/10823
< cfields> sipa: interesting. clang doesn't enable -fomit-frame-pointer at any optim level
< cfields> adding that in fixes compilation
< luke-jr> doesn't it break debugging?
< bitcoin-git> [bitcoin] promag opened pull request #10824: Avoid unnecessary work in SetNetworkActive (master...2017-07-set-network-active) https://github.com/bitcoin/bitcoin/pull/10824
< cfields> luke-jr: it's on by default for x86_64
< cfields> er, for gcc
< mmgen> arubi: now redeem script is correctly formed, signrawtransaction is including the witness data, but txsend fails with 64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code -26)
< mmgen> input in question is output 0 of testnet tx dd2117779039b6abd20529c9c9ce67b4c18c0a0223129759ae01deebaa037151
< mmgen> wif: cVGLmgcfnq2jvdhNFn9UJQWe6NUCr71GMHePKZC8eXc6fNdJsRuM
< mmgen> addr: 2N3wYVH1n51ucjnGR2fjcqb6GPeUmDxQH3h
< arubi> mmgen, then your sig is not valid. it's too off topic here. we can move to #bitcoin-dev if you want
< mmgen> arubi: agreed, this is offtop, but #bitcoin-dev requires registration doesn't it?
< arubi> oh I don't know..
< mmgen> think it does. How do I go about that?
< arubi> that's something done through nickserv
< Chris_Stewart_5> it does
< Chris_Stewart_5> and I have no idea why it does :/
< arubi> yea it's an overkill
< mmgen> yet #bitcoin-core-dev doesn't
< mmgen> I'm working on registration now
< mmgen> sent the request
< morcos> promag: Your question before about the buggy output. That isn't buggy as far as I can tell. What did you not like? The -1's?
< promag> nan
< morcos> oh i think we covered that before and determined it was fine to divide by 0 (it's only for outputing text) and in this case there are no txs in the denominator
< promag> for reference the output is: Fee Calculation: Fee:4520 Bytes:226 Tgt:6 (requested 6) Reason:"Fallback fee" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)
< morcos> yeah so that tells me there were no data points in your fee estimation
< promag> right, but in the UI it says: "Warning: Fee estimation is currently not possible"
< morcos> promag: yes exactly.. and the debug log is telling you exactly why it is not possible. no data points. it could have also indicated some smaller number of data points, or enough data points but no fee rate high enough that meets the passing threshold for your target
< morcos> that debug log output is just for help determining exactly why a particular fee is put on a transaction.
< morcos> gmaxwell: speaking of which we'd recently discussed making the fallback fee higher than 20 sat/b. I think we discussed 50 or 75. The thinking at the time is 20 is often not high enough to ever get confirmed.
< morcos> But perhaps we were over influenced by a short period of congestion?
< promag> ok then morcos, thanks
< morcos> In any case, I'd still be ok with 50 or 75 as the default for fallback.. I don't think its so unreasonably high that people would complain if they paid that if fee estimation wasn't working
< morcos> The downside is if fees drop substantially over some period of time, lets say BTC goes up 10x, and then paying 75 sat/B is actually kind of a lot. I suppose it's a no win situation for getting the right number here.
< morcos> Maybe the answer is to not touch the default but give advice in release notes about setting that number appropriately?
< bitcoin-git> [bitcoin] fametrano opened pull request #10825: Net set regtest JSON-RPC port to 18443 to avoid conflict with testnet 18332 (master...fametrano-regtestport) https://github.com/bitcoin/bitcoin/pull/10825
< To7> Core dev, time to protect Bitcoin differently.
< instagibbs> is there reasoning for sendrawtransaction bypassing free relay limit?
< instagibbs> oh im hallucinating, it doesn't
< instagibbs> (anymore)
< sipa> cfields: adding -fomit-frame-pointer sounds like it may in general improve performance then...
< cfields> sipa: I'm not sure if clang/ld64 add necessary debug sections, though
< bitcoin-git> [bitcoin] Thecave3 opened pull request #10827: fixed grammar error (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10827
< BlueMatt> who uses listsinceblock?
< BlueMatt> anyone?
< cfields> sipa: i'll experiment
< instagibbs> BlueMatt, there exists users... why
< BlueMatt> without looking at the code (just the docs), can folks tell me what they think the "target_confirmations" parameter means in listsinceblock?
< BlueMatt> "2. target_confirmations: (numeric, optional) The confirmations required, must be 1 or more\n"
< Murch> Is anyone aware of best case practices regarding path derivation of segwit addresses?
< Murch> We currently have two paths for receive and change addresses, and we're considering to adding another two paths for segwit receive and change addresses.
< instagibbs> Murch, there are none right now AFAIK. BIP49 I think is the only proposed one for Mycelium or something
< BlueMatt> instagibbs: ahh, ok, that still leaves me wondering what in the fuck the purpose of that argument is
< Murch> instagibbs: Thanks, I'll take a look.
< instagibbs> Murch, I'd suggest asking various wallet authors, don't think there's consensus on that at all
< Murch> What would be a good way to reach them? Would that perhaps be worth a mail to the bitcoin-dev list?
< BlueMatt> instagibbs: care to ack that? I find that astoundingly poor docs, should fix for 15 if possible
< instagibbs> BlueMatt, asking the author, I have actually no clue
< BlueMatt> the docs on 10655 make it a bit more clear, ie if you care about when things hit 6 confs, you calling listsinceblock with old blocks each time so that you keep getting reminded of things with 6 confs
< BlueMatt> and then you filter for txn with 6 confs yourself
< BlueMatt> still seems a super strange api to me, but i can see why it would be useful
< instagibbs> Murch, yeah I think so. Also bug bigger players individually maybe
< Murch> instagibbs: Thanks for the consult. ;)
< cfields> sipa: heh, not a good sign: Assertion failed: (consensus.hashGenesisBlock == uint256S("0x000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943")),
< cfields> makes for a good backtrace example, though: https://pastebin.com/raw/kA3bavgA
< sipa> cfields: bah, i could make it manually save and restore the frame.pointer during the duration of the asm blocm
< cfields> sipa: that's with 10821 and -fomit-frame-pointer
< cfields> no clue if that's the cause of the failure, or something else busted
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/db825d293be8...66270a416edb
< bitcoin-git> bitcoin/master 18bacec Alex Morcos: Make check to distinguish between orphan txs and old txs more efficient....
< bitcoin-git> bitcoin/master 66270a4 Pieter Wuille: Merge #10557: Make check to distinguish between orphan txs and old txs more efficient....
< bitcoin-git> [bitcoin] sipa closed pull request #10557: Make check to distinguish between orphan txs and old txs more efficient. (master...dontcheckoutputs) https://github.com/bitcoin/bitcoin/pull/10557
< bitcoin-git> [bitcoin] Thecave3 closed pull request #10827: fixed grammar error (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10827
< jonasschnelli> hmm.. we should add bench to the gitian build/exported binaries
< sipa> cfields: could you send me a disassembled version of that function?
< cfields> sipa: sure, give me just a few min
< cfields> i managed to get it working when built from yasm
< bitcoin-git> [bitcoin] ryanofsky opened pull request #10829: Simple, backwards compatible RPC multiwallet support. (master...pr/multiparam) https://github.com/bitcoin/bitcoin/pull/10829
< sipa> cfields: the code here was an attempt to actually translate it to extended asm, where the compiler still manages the stack and register allocation
< sipa> cfields: i can go for the more straightforward way of just making it produce literally the same bytecode as yasm, where the asm is responsible for saving/restoring registers etc
< cfields> sipa: understood, i just wanted to get a working asm dump to compare to
< cfields> heh, no clue what all this padding is about
< cfields> i snipped the padding
< cfields> for comparison, yasm's output: https://pastebin.com/raw/Sk3BfXyW
< cfields> note that I had to -DLINUX with yasm, otherwise I'd get the same crash
< BlueMatt> sipa: can you mark 10807 as 0.15 (or merge it) since easy bugfix
< bitcoin-git> [bitcoin] jnewbery opened pull request #10830: [WIP] [wallet] keypool restore (master...pr10240) https://github.com/bitcoin/bitcoin/pull/10830
< jnewbery> #10830 is #10240 rebased on master. Please mark it as high priority & 0.15
< gribble> https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
< cfields> sipa: may also be helpful to know that the resulting hash is: 19cde05babd9831f8c68059b7f520e513af54fa572f36e3c85ae67bb67e6096a
< cfields> (initial sha2 state)
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #10240: Add HD wallet auto-restore functionality (master...2017/04/hd_rescan) https://github.com/bitcoin/bitcoin/pull/10240
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66270a416edb...b7d6623c76e1
< bitcoin-git> bitcoin/master 4652791 João Barbosa: Fix uninitialized atomic variables
< bitcoin-git> bitcoin/master b7d6623 Pieter Wuille: Merge #10819: Fix uninitialized atomic variables...
< bitcoin-git> [bitcoin] sipa closed pull request #10819: Fix uninitialized atomic variables (master...2017-07-fix-unitialized-atomic) https://github.com/bitcoin/bitcoin/pull/10819
< sipa> cfields: i can make the code use one less register
< cfields> sipa: i've been trying to figure it out :)
< cfields> sipa: i think you can shortcut the end address calculation?
< sipa> cfields: if you look at the yasm source, NUM_BLOCKS and e use the same register
< sipa> one uses it in 32-bit mode (edx) and one in 64-bit mode (rdx)
< sipa> which my search/replacing treated as two different things
< cfields> ah
< cfields> ok i see, that makes sense. That's the one I was trying to save as well. But so far I'd just managed to piss off the assembler in a bunch of different ways.
< sipa> cfields: so s/%7/%k2/
< sipa> %k2 means "the same as %2, but in 32-bit mode"
< sipa> and then more shuffling to get rid of the e variable...
< cfields> roger
< cfields> sipa: i'm confused as to why inp_end can't be pre-calculated and passed as an input, skipping %2 altogether?
< sipa> cfields: we could move that out to the C code, yes
< sipa> the asm code really uses a begin_ptr and end_ptr
< sipa> and the first 3 instructions convert the (begin_ptr, num_blocks) to that
< cfields> sipa: right ok, thanks. no need to do that rather than your approach ofc, but it helps to know that would've worked
< gmaxwell> sipa was in the process of changing everything to use explicit registers and then he was going to manually save bp on the stack so he could use it and restore it at the end.
< sipa> this approach now should be faster
< sipa> as it only saves/restores exactly what is needed
< cfields> testing now
< sipa> cfields: thanks!
< cfields> sipa: builds now, but still produces a busted hash :(
< sipa> :'(
< sipa> cfields: with or without -fomit-frame-pointer ?
< cfields> without now
< cfields> i'll try without the stack protector
< cfields> same thing
< sipa> cfields: i can try force assigning variables to registers, to make the code comparable to the yasm code?
< sipa> to make sure the same assignment is used
< cfields> sure
< cfields> sipa: from what i can see, the input is no longer necessarily 32bit aligned
< cfields> is that a possible issue?
< sipa> cfields: oh!
< sipa> how do you mean?
< cfields> let me double-check, i might've reversed something in testing
< cfields> sipa: yea, the ReadBE32 on the chunk guaranteed alignment before, without that, is something else handling it?
< sipa> cfields: the asm code can deal with unaligned input data
< cfields> ok
< sipa> cfields: i think that the xfer array may need stronger alignment than the compiler is giving it
< sipa> cfields: care to try again?
< cfields> sure, i'll take a break from fighting this thing.
< cfields> heh, i was trying the same thing, but i pissed it off trying to make it 32bit aligned
< cfields> no go :(
< sipa> same error?
< cfields> yea. you just added the attribute, right?
< sipa> yes
< cfields> btw, that can be alignas(16) with c++11
< cfields> generated asm now: https://pastebin.com/raw/SRe0gzUf
< cfields> any clue what the huge chunk of padding is?
< sipa> the nopws?
< sipa> cfields: can you try changing the movdqa instructions to movdqu ?
< sipa> (a = aligned, u = unaligned)
< cfields> yea, 0x91 through 0x10000
< cfields> ok
< cfields> nope :(
< sipa> cfields: my guess is that to the OSX assembler ".align 16" means "align to a 2^16-byte boundary"
< sipa> instead of "align to 16-byte boundary"
< cfields> ah
< sipa> cfields: pushed again, try again pretty please?
< cfields> heh, sure
< sipa> added some more alignas'es
< sipa> i think there are instructions beyond movdqa that require aligned input
< cfields> still no go
< cfields> you saw me mention that the result is always the sha2 init values, right?
< sipa> oh, no
< cfields> hash is "19cde05babd9831f8c68059b7f520e513af54fa572f36e3c85ae67bb67e6096a"
< sipa> cfields: you're aware the yasm function takes its parameters in a different order?
< cfields> yes, i had to reverse them to make it work
< sipa> grrr
< sipa> i really don't see how the state can be untouched with your disasm code... unless blocks=0
< cfields> i'm stumped too. It gets in there sometimes with blocks=0, but even if I early-return, same result
< sipa> can you give a latest disasm?
< sipa> can you step through it with a debugger, to see if it's actually doing anything?
< sipa> (stepi in gdb will execute 1 instruction)
< cfields> i've tried to get in with no luck
< cfields> i can try again
< cfields> (it's lldb, and i'm not at all familiar with it)
< sipa> cfields: just some thing i'm noticing from the latest disasm you posted: the stack pointer isn't being updated, but is addressed with negative offsets (which is legal, but different from other platforms)
< sipa> it also saves and restores the frame pointer, but does not actually use it
< cfields> sipa: i noticed the negative offsets too. how can that be the case?
< sipa> cfields: it's legal to use some stack space below the stack pointer (google for red zone)
< sipa> if you want to set a breakpoint, set it to the loop2 label
< cfields> interesting
< sipa> if loop2 is reached, it should always update the context
< cfields> that's a rabbit hole for a different day though :)
< sipa> (the updating happens in the addq/movq sequence right before done_loop)
< sipa> eh, addl/movl
< sipa> can you just post a latest disasm? :)
< cfields> haha, 1 sec
< cfields> uh, I switched to -O0 for better debugging, let me know if you want an -O2 to match the others
< cfields> i assume it doesn't matter much here
< cfields> i was just trying to get it un-inlined
< cfields> (it wasn't anyway. oops)
< sipa> cfields: my latest code just doesn't compile with clang 4.0
< sipa> are you sure you're testing the right thing?
< cfields> i moved the alignas's around
< cfields> if that's what you mean
< sipa> ok
< sipa> yes
< sipa> trying to reproduce on linux
< cfields> i tried dumping the dispatcher and hard-coding the call instead
< cfields> thought there might be some static init race. no help though.
< sipa> what clang version are you using?
< cfields> stupid apple...
< cfields> Apple LLVM version 7.3.0 (clang-703.0.29)
< cfields> no clue what ^^ is
< cfields> let me see if a cross build works, then we'll have an upstream clang for data point
< sipa> works fine with clang-4.0
< sipa> trying 3.7 now
< sipa> eh, 3.7 fails on some c++11 stuff
< cfields> for reference, i'm building with 3.7.1 now for cross
< cfields> eh?
< sipa> In file included from ./httpserver.h:10:
< sipa> /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/functional:1370:11: error: no matching constructor for initialization of 'std::tuple<packaged_task<bool (event_base *, evhttp *)>, event_base *, evhttp *>'
< cfields> c++ lib issues?
< sipa> : _M_bound(std::forward<_Tp>(__f), std::forward<_Up>(__args)...)
< sipa> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
< sipa> why is it using gcc-6.3's include dir?
< cfields> give it -stdlib=libc++
< cfields> (you might need LD_LIBRARY_PATH set to run)
< cfields> ok, cross with 3.7.1 dies the same way
< sipa> ok, compiling with 3.7.0
< sipa> /home/pw/git/bitcoin-shasse/src/util.cpp:861: undefined reference to `boost::filesystem::path::imbue(std::__1::locale const&)'
< cfields> heh, your boost was built against libstdc++
< sipa> can i do a depends build on linux with clang?
< sipa> on/for lnux
< cfields> you can probably just do up a tiny stub app using CSHA256 directly, no?