64 bits Window binary compiled with VS 2013
It has been two weeks since the Hardfork, there is no Window Binary available except the one cross-compiled by @steem-id.
I need one for my own testing, so I decided to compile one myself. I followed @bitcube's guide, run into many issues, but I got it to compile.
I've test mining with 4 cores on an i7 machine for over 24 hours without any issues.
Here is the 64 bits Window binary if anyone still interested in CPU mining.
Update:
The Dropbox link is no longer working, Please download from github.
https://github.com/alphab3ta/steem/releases/tag/v0.14.2
https://www.dropbox.com/s/mhf1wnzee30cfmq/steemd14.2.zip?dl=0
sha-256 checksum:
5535BB5E791236C65408184A606DA87FED0B8BC3D1AECF3B13834E9EB944E7B2
Excellent job!
However, i need to ask, will you publish the source? Using miners and keys with closed source is kinda.. Hmmm..
Win executables are perfect for hiding things inside. I'm not saying you did, but it's a matter of time before people will ask or state you did.
Love this, following you!
Thank you!
Maybe I will post the source later today when I have the time.
Save me the trouble posting all the code change on a post.
Great job @alphabeta!!!
Can you share your build tutorial/patch?
Thank You @ steem-id.
Maybe on the next post.
Nice!!
I'm stuck on this error:
Unable to debug because I'm not a programmer :(
I am not a c++ programmer either.
I look at @bitcube's original source and modified accordingly.
On node cpp line 4221
after that you will encounter few more issues, and more code modification before its able to compile.
Looks like that change is made by me, which is to address a node stuck issue. I'm not sure why it doesn't compile on vs though. Perhaps just need to add a whatever variable to the inner
(()), for example make itFC_CAPTURE_AND_LOG( (_user_agent_string) ). Need testing.//Update: after made above change, at least the project still compiles in Ubuntu. I have no VS env, so need your help to test out.
I will test it when I can.
Hi @abit,
I did a test with above code
FC_CAPTURE_AND_LOG( (_user_agent_string) ), it compiled fine with VS2013. But after it fully syncs, it crashed, not sure why.I would like to ask you a different question.
when I was compiling cli_wallet, I got
error C2593: 'operator <' is ambiguouswhich is caused by found using ADL on ip.hpp(60).
F:\winsteem\steem\libraries\fc\include\fc/network/ip.hpp(60): could be 'bool fc::ip::operator <(const fc::ip::endpoint &,const fc::ip::endpoint &)' [found using argument-dependent lookup] while trying to match the argument list '(const fc::ip::address, const fc::ip::address)'.I try to overload the operator by adding a line
friend bool operator<(const address& a, const address& b);,it gives me different error LNK2019 & 2020 unresolved externals. So I end up omitting line 60 from the ip.hpp file. then it compiles without issues.
The question for you is what is the best remedy for this error?
I'm replying here due to reached maximum nested level. Sorry for the late reply.
Crash every time after fully synced? Logs and/or core dump etc would be useful.
It seems that in the
cli_walletcode somewhere there is a comparison between twoaddressobjects, butclass addresslack of aoperator <. Tryfriend bool operator<(const address& a, const address& b);toclass address, andUpdate2:
Thank you @abit. All the below code change compiled without error.
Except the latest commit. It has 7 error:
4 reference to raw.hpp line 294:
c2668: fc::raw::unpack : ambiguous call to overload functionand 3 reference to variant.hpp line53:
c2668 fc::from_variant : abmiguous call to overload funciotnI don't think it is related to the code change.
"raw.hpp line 294" and "variant.hpp line53" don't contain code in my repository. Would you please share us the whole error message, or just post in an new issue to your own github repository and post the link here? Thanks
Ok. I will try that later.
Thank you. Upvoted and resteemed. Guess I'll give it a try for a couple days and see how it does. Did you get any blocks in your 24 hour trial?
No block, it is not fast enough to compete with @rabbit & @supercomputing.
Right. Before the hardfork, I was squeezing out a block every day or two. The target and queue length are a little bit higher now, though. If I don't get any blocks before Wednesday and the cost of steem stays low, I'll go back to mining indirectly through nicehash, using the method I described here. I've been getting about 5 steem per week that way.
Anyway, thanks again for doing this work and putting the binary out there.
I stop mining once @rabbit & @supercomputing taken over the miner queue.
This post has been linked to from another place on Steem.
Learn more about linkback bot v0.4. Upvote if you want the bot to continue posting linkbacks for your posts. Flag if otherwise.
Built by @ontofractal
FYI, there's a mining patch from @penguins (penguin on golos) via @picokernel that improves mining performance. Unpatched PCs are only running with one effective core, no matter how many threads are configured.
@contentjunkie has distributed a compiled binary for windows, but for some reason that version doesn't seem to be working properly in my environment. I tried on 3 different PCs and can only get it to use 1 actual core, no matter how many threads I set in config.ini.
I saw that yesterday and compiled a binary with it. I did not see any hashing power improvement but it found a block for me just half hour ago.
I did not post on Github yet.