I built the steemd.exe and cli_wallet.exe executables using the process described in the OP for the code as of this commit. So that code is actually ahead of v0.4.3.
I have made those executables available in a zip file available at this link for anyone who really wants to play around with it now and doesn't have access to a Linux system (or doesn't want) to build it themselves.
Because steemit.com is being very foolish right now (it refuses to let me create a link to IPFS without automatically treating it like an image) I have to provide the link in a code block:
https://gateway.ipfs.io/ipfs/QmbFbd3MYj6LrRjPFKPUkzUHMEtAdnHMDqfW7NXzjMt3Ah
That download link is to an IPFS gateway. So it should download to your computer to a filename like QmbFbd3MYj6LrRjPFKPUkzUHMEtAdnHMDqfW7NXzjMt3Ah. You need to rename it to a zip file like steem.zip and then you can extract the two executables inside.
If you have sha256sum.exe on your computer (I recommend getting it), you can verify that the zip file you downloaded is good by comparing it to the following sha256sum:
4e6af58981554991e2d9a29a49adbd8eb6a52b8d8149f0cb6d143189c84fc607
If you don't get the above sha256sum for the file you download, then it isn't the correct file and I cannot guarantee the safety of what you run.
If you have 7-zip installed, it automatically puts a "CRC SHA" context menu in Windows Explorer. Right click the .exe, CRC SHA -> SHA-256. Capitalization of the hash doesn't matter.
Great tip. Although, I should mention that the SHA256 sum I included in the post is of the downloaded zip file, not of any of the exes.
Ive used this guide to successfully make working 0.11.0 builds of Steem for Windows, thanks!
One question, unlike Bitcubes's build, the compiled versions Ive produced are massive, like 20MB executables. They are also slightly slower (5%). I even edited the your handy scripts to build shared lib versions and it made no difference.
Any idea what would cause this.. is it as its cross compiled? Id love to get better at compiling/porting stuff, so any tips appreciated! :)
I would have said they are larger because it is a fully static build, but apparently you are saying based on your attempts it isn't much better when using shared libraries. So, I am really not sure. Are the shared lib versions you made using Boost and OpenSSL as the shared libs? What is the size difference in the files (both the reduction in the cli_wallet.exe and steemd.exe files individually as well the net change, if any, between all necessary files to run cli_wallet and steemd together before and after the shared lib version)?
Perhaps it can be explained by the fact that bitcube's executables require "Visual C++ Redistributable Packages for Visual Studio 2013" as a dependency to run, but the MinGW compiled versions do not because any relevant code dependencies are already included in each of the executable? Again, just a guess and not something that I'm certain about.
I think the performance difference may be explained by the fact that this guide does not use GMP/MPIR which I believe bitcube does use in his builds (although I may be wrong about that; can I get clarification about that @bitcube?). You could follow the guides floating around on how to use GMP and make the necessary modifications to my guide and build scripts to have the MinGW Windows build use GMP as well. It is a slightly more difficult task with the cross-compile build because you first need to cross-compile GMP as an additional dependency in addition to OpenSSL and Boost.
By the way, I would love to see your modifications to get the shared libs working, if you are willing to share them. Maybe you can put up your own modified guide as a post for some upvotes. Also, if you get GMP working in the cross-compile build, I think that is worthy of a guide as well.
I basically just added "link=shared" to Boost and "shared" to the OpenSSL helper scripts in the appropriate section. This produced files about 2mb smaller (each), but still way bigger than Bitcubes (6mb vs 20'ish).
Ive made some tweaks to OpenSSL's and Boost build options and testing right now too. Looking at GMP now too, to see how possible it is!
Within configure_build.py I found this:
Maybe add Windows cross-compilation flags
if args.windows: mingw = "x86_64-w64-mingw32" command.append("-DFULL_STATIC_BUILD=ON")--
I tried changing to DFULL_STATIC_BUILD=OFF but during compile it seemed to complain about it and put it back on. I suspect this is causing the mammoth 20mb exe's?