23800+ entries in 0.073s
mod6 thanks asciilifeform for building the portotronic & build script
mod6: <+mod6> we'll see if it passes 160001 << derp. 168,001
mod6: we'll see if it passes 160001
mod6: v0.5.3 base + patches { 1, rm_rf_upnp, 2, 3, 4, 6 & 7 } + openssl 1.0.1g with a modified portotronic build script - all statically linked libs
mod6: wow, this thing is really flying
mod6: im already at 100k blocks.
mod6: the last 3 commands of that build script never seem to run for some reason
mod6: ah, no that's not stripped.
mod6: already have 11k and counting
mod6: It's a shit-blizzard, Randy.
mod6: <+mircea_popescu> jurov why not run a bitcoin host ? we kept wanting it << yeah!
mod6: everytime i've ever followed -current i end up with a lot of panic!s
mod6: current = uber-crasher
mod6: no -STABLE is stable
mod6: ok. no problem. just trying to get it down to a spec
mod6: i thought we didn't want to use shared libs? only static libs *.a's
mod6: asciilifeform: ben_vulpes might have the same problem with his, is there something he should be specifically looking for in the elf?
mod6: asciilifeform: no, i didn't im currently rebuilding.
mod6: is it appropriate to do `make LMODE="static" LMODE2="static" -f makefile.unix bitcoind` instead?
mod6: asciilifeform: in your portotronic script, the line `make STATIC=1 -f makefile.unix bitcoind` ends up doing "-Wl,-Bstatic ... -Wl,-Bdynamic" when actually executed because of the bug in the makefile.
mod6: (always past the last checkpoint, but usually before 252450)
mod6: *nod* i wanna say that mine usually blows up around like 200-230k or w/e
mod6: BingoBoingo: ah, yeah cool. :]
mod6: no, havnet tried it. ben is building it currently actually. thanks.
mod6: im still wrestling with trying to compile bitcoind on linux with statically linked libs & objects.
mod6: so ~10mb /difference/
mod6: that was on obsd. which subsequently coredumped on execute
mod6: dynamically linked ~18mb, statically linked (that didn't work) ~28mb
mod6: yeah, im sure i did.
mod6: Anyway, none of this really matters until we can get a statically linked build.
mod6: There's a lot of moving parts in there, and deps. It's hard to put a finger on what exactly it is, right now. Especially since we are all using slightly different environments. Too many variable.s
mod6: We'll figure it out at somepoint. I think, for now the important thing is that we have a workaround.
mod6: as you just proved, it'll make it past it sometimes, and sometimes not. im sure there is some sort of reason for this, but we dont know what it is at this time.
mod6: thestringpuller: no.
mod6: it probably will take a while.
mod6: aight. so yeah, stay tuned. as soon as I get anything working with static libs and static linking of the output object files from the bitcoin source base, I'll give an update.
mod6: makes for a larger output binary (by about 10mb) but is more safe incase someone were to do something nasty with a lib that is dynamically linked
mod6: it will build all of the necessary things inside of the output binary, instead of leaving that stuff to call out to a seperate place
mod6: for the last 48 hours i've been working on trying to get it to build against static libs.
mod6: which we won't support.
mod6: it'll build, it'll build the `bitcoind` binary dyamically linked.
mod6: when statically linking via the makefile.unix that's included with v0.5.3, I can't even get mine to compile correctly. So, I'll be spending a lot of time probably re-writing the entire makefile
mod6: ok thats awesome. although, i think what everyone has been running up to now is a dynamically linked version of the output binary. which shouldn't even be availab.e
mod6: thanks for testing. if you put together a pastebin of your findings: `./bitcoind getinfo` `openssl version -a`, etc. that would be helpful for our permutation matrix
mod6: you might be the first to be testing on deb7, not sure.
mod6: we're running on squeeze (deb 6)
mod6: you're on debian 7 right?
mod6: ok 180631 and no errors, looking good. see, it's inconsistant :)
mod6: so its totally inconsistant
mod6: and recently, TomServo was able to fully sync the blockchain with config: v0.5.3 + patches + { 1, rm_rf_upnp, 2, 3, 4, 6 & 7 } AND with openssl v0.9.8o
mod6: well, remember, I've personally gotten past that block probably a dozen times with openssl 0.9.8o with config: v0.5.3 + patches { 1, rm_rf_upnp, 2, 3, 4, & 6 }
mod6: thestringpuller: np
mod6: If you got past 168,001 without any erros reported in `./bitcoind getinfo` then you should be alright.
mod6: <+thestringpuller> mod6: ben_vulpes it got past the wedge <+thestringpuller> "blocks" : 164713 << looks to me like you just hit a spot where it was slow, maybe a lot of disconnected blocks. this isn't the "wedge" block we were hitting. tx we had issues with (VerifiySignature) was in block 168,001. It's all in the logs.
mod6: if so, then yes, you hit the bad tx, and then you need to upgrade to openssl 1.0.1g to pass over it.
mod6: Might need some help on these ones for sure.
mod6: This might be a show-stopper, will for sure need to fix before release.
mod6: thestringpuller: dont forget to give us a paste of the info though! plzkthx
mod6: thestringpuller: ben & I were able to pass it once we upgraded to v1.0.1g
mod6: but good to know anyway.
mod6: well, so we think. but its not really apples to apples since that code base is so much different.
mod6: you're on 0.7x tho right?
mod6: i suppose anything is possible.
mod6: doesn't mean that a few bad seeds aren't out there though. more research required.
mod6: danielpbarron: i don't have any evidence to support that.
mod6: there would be 95% less people on the tubes if they had to compile everything themselves. ``THE BARRIER TO ENTRY IS TOO DAMN HIGH!.jpg''