< cfields> clang?
< BlueMatt> jtimon: hmm? I havent made it....since its likely to conflict like hell with everything I figure I should probably prep it when everything else is reviewed and in
< BlueMatt> instead of rebasing constantly
< Lightsword> cfields, does the default clang on debian 7 support c++11?
< Lightsword> hmm, would appear debian 7 is default version 3.0 and min is 3.3 for c++11
< jtimon> BlueMatt: ok
< BlueMatt> jtimon: it should be +/- the same as the branch I gave you about a month ago
< BlueMatt> I think the current prs are all still that branch rebased without any major changes
< jtimon> BlueMatt: yeah was just curious on your plans about it
< sipa> Lightsword: that's annoying...
< sipa> Lightsword: you could compile a static binary on a later system
< Lightsword> sipa, yeah that’s what I recommended
< cfields> the release binaries should be fine for that unless it needs patching
< BlueMatt> cfields: hey
< BlueMatt> cfields/sipa: sorry, been missing all day, happy to chat about CConnman design if y'all're free, or can wait till tomorrow
< phantomcircuit> anybody have an opinion on where fuzzing examples should go? (ie which directory)
< phantomcircuit> i was thinking contrib
< luke-jr> phantomcircuit: under qa/?
< BlueMatt> luke-jr: only if there is infrastructure to automatically run them (travis, or if its too slow, at least some scripts)
< BlueMatt> but, yes
< phantomcircuit> luke-jr, yeah that sounds better
< meownow> can anyone summarize when i download the bitcoin source code on the github, what is the client i am downloading able to actually do?
< achow101> meownow: it fully verifies all blocks and transactions, relays said blocks and transactions, can manage a wallet, does signing operations with ecdsa keys, produces block template for miners
< meownow> ok thanks. so with it i can donate my cpu to acting as a node to store and verify blocks and transactions, which other nodes will very their own blocks against? as well as the other things you mentioned i can do.
< achow101> no, nothing is verified against someone else. your node has a set of hard coded rules and it will verify blocks and transactions according to those rules. every other node will do the same, verify the block against the built-in rules
< gmaxwell> Oh good, I was worrying that my C++ compile times were getting too fast https://github.com/kw-udon/constexpr-8cc
< bitcoin-git> [bitcoin] laanwj opened pull request #9190: qt: Plug many memory leaks (master...2016_11_plug_leaks) https://github.com/bitcoin/bitcoin/pull/9190
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9346f8429957...ce612f175063
< bitcoin-git> bitcoin/master 12519bf Wladimir J. van der Laan: test: Fix use-after-free in scheduler tests...
< bitcoin-git> bitcoin/master ce612f1 Wladimir J. van der Laan: Merge #9186: test: Fix use-after-free in scheduler tests...
< bitcoin-git> [bitcoin] laanwj closed pull request #9186: test: Fix use-after-free in scheduler tests (master...2016_11_scheduler_fix) https://github.com/bitcoin/bitcoin/pull/9186
< meownow> im currently reading through the first commit of the bitcoin source code onto github. seems a good way to familiarize myself with the core of the code base and what it does.
< instagibbs> meownow reading code that relates to specific issues or pull requests helps me the most
< luke-jr> instagibbs: he left.
< luke-jr> but in case he reads the log: I don't recommend reading the earliest code as a way to learn about Bitcoin. It was a mess, and included a lot of features later discarded (eg, built-in marketplace)
< gmaxwell> I don't agree it was a mess. it was also quite short, there were some irrelevant parts to skip over... sure.. but it's much easier to read than the current codebase if for no other reason than size.
< sipa> it's probably a relatively good way to understand the design of bitcoin, but it's not that helpful to learn how the code works now
< BlueMatt> hmmm....whens the last time anyone built with lto?
< sipa> BlueMatt: i did a few months ago
< luke-jr> gmaxwell: well, it certainly wasn't as modular/abstracted as it is now
< BlueMatt> sipa: what did you have to do it?
< luke-jr> unless things got significantly worse by 0.3.19 which is probably the oldest I've actually looked over much
< sipa> BlueMatt: it was hard :)
< BlueMatt> oh :(
< BlueMatt> still have patches?
< luke-jr> O.o
< sipa> no patches, just a long ./configure line
< BlueMatt> still have it in .bash_history? :p
< sipa> nope
< luke-jr> I would think you'd just need to build/link everything with -flto? no?
< luke-jr> (including system libs..)
< BlueMatt> sipa: did you have to set ar=gcc-ar, etc?
< BlueMatt> luke-jr: lolno that dont work
< sipa> luke-jr: if you do everything through gcc, it will work
< sipa> but not if you invoke ld, ar, ... directly
< sipa> BlueMatt: i remember that it needed absolute paths for those tools
< sipa> and that it took me hours to figure that out
< sipa> or something like that
< luke-jr> as long ago as 2012, this user got his system including KDE all LTO'd: http://realnc.blogspot.com/2012/06/building-gentoo-linux-with-gcc-47-and.html :p
< BlueMatt> sipa: see? you already saved me a bunch of time :)
< luke-jr> that -fno-linker-plugin might be related to that
< sipa> BlueMatt: i think this works:
< sipa> ./configure AR=/usr/bin/gcc-ar NM=/usr/bin/gcc-nm RANLIB=/usr/bin/gcc-ranlib CPPFLAGS="-O2 -flto" CFLAGS="-O2 -flto" LDFLAGS="-flto" --with-incompatible-bdb
< sipa> or CXXFLAGS maybe
< BlueMatt> sipa: nope, still getting the same shit i was previously: undefined reference to boost::filesystem::path::~path()
< BlueMatt> (which is implicitly defined, i checked)
< BlueMatt> via bitcoin_util.a
< sipa> BlueMatt: worked for me (gcc 6.2.0)
< BlueMatt> 6.2.1 here w boost 1.62
< sipa> and boost 1.54
< luke-jr> what distro is using GCC 6 already? :o
< gmaxwell> luke-jr: fedora, arch, debian testing?
< luke-jr> hmm, does that mean all of Debian compiles with it? or do they have older compilers used for some pkgs?
< luke-jr> sorry, kinda off-topic, I'll just google
< gmaxwell> I dunno about debian, but when fedora releases with a new gcc, all of fedora compiles with it (potentially carrying patches to both GCC and a few packages).
< luke-jr> just surprised considering Gentoo stable is still on GCC 4
< sipa> luke-jr: ubuntu 16.10
< sipa> has gcc 6
< sipa> i don't know whether they use that for release binaries, though
< gmaxwell> netcraft confirms, gentoo dying.
< sipa> netcraft confirms: netcraft dying
< luke-jr> lol
< luke-jr> well, at least it seems there are real blockers to GCC 6: https://bugs.gentoo.org/show_bug.cgi?id=582084
< sipa> gcc6 by default compiles with c++14
< sipa> perhaps some packages don't explicitly set the c++ version?
< luke-jr> could be
< BlueMatt> luke-jr: a brief glance at some of those bugs indicates that they're just sitting idle with no desire to merge dead simple patches
< BlueMatt> indeed, gentoo is dying
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #9191: [qa] 0.13.2 Backports (0.13...Mf1611-q01302) https://github.com/bitcoin/bitcoin/pull/9191
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ce612f175063...44adf683ad23
< bitcoin-git> bitcoin/master dfa44d1 Russell Yanofsky: [qa] Wait for specific block announcement in p2p-compactblocks...
< bitcoin-git> bitcoin/master 44adf68 MarcoFalke: Merge #9159: [qa] Wait for specific block announcement in p2p-compactblocks...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9159: [qa] Wait for specific block announcement in p2p-compactblocks (master...cmpct-announce-wait) https://github.com/bitcoin/bitcoin/pull/9159