When compiling the daemon, just use the standard make -f makefile.unix
Thanks! The compilation works now with Boost 1.54. Unfortunately, the daemon still crashes (segfaults) about ~10 minutes after startup (as before, last sign of life in debug log is the "CBlock" line). I will test the newest code now on my other machine.
That's clearly unsatisfactory, I shall investigate further. AIUI, this is on Ubuntu Trusty? Is that on a 32-bit or 64-bit architecture? (I seem to have acquired two “Trusty” VMs, one for a 64 bit arch, one for a 32-bit but I have little idea whether the difference has any effect unless the actual machine on which I'm running it is 32-bit).
Just a small question about the version numbering: Am I right that the "prerelease" branch would be the "stable" 0.4 version and the master branch is meant to be 0.5? Or are both 0.5? It's because I plan to update the OP a bit with the newest developments.
Now that the dust is beginning to settle on the codebase, we can switch the default github repos back to "master" and use the 0.5 tag to distinguish the supported Linux “0.5 release” build and use the release page to offer downloadable 0.5 binaries for Windows and OS X. Then we can return to the standard “developers work in their own branch” approach. The current “slimcoin” branch can simply be renamed to “slimcoin 0.4”.
As far as I can figure out from reading the source code, the release version advertised by the running app is taken from the last git tag (which explains why changing the version number in
version.h seems to have no effect).
Locally, I could tag my clone as 0.6.6.6, compile the app and the running app would report 0.6.6.6. If I were to push that tag to the public repos, all subsequently cloned+compiled apps would advertise themselves as 0.6.6.6.
There's a 6th-level git wizard's spell of push-release-tag-to-public-repos to be uttered at some point (RTFM, Graham). After this, the GitHub repos “release” page can then be loaded with the (correctly-functioning) platform-specific binaries of Slimcoin 0.5 for Windows and OS X.
Organic life-forms are advised not to try this with Linux binaries because, basically, there's only one supported latest version of Windows and OS X and therefore static libs are reliable on those platforms whereas that is not the case with Linux where dynamic libraries are the norm (AIUI). I could offer Linux builds that link against dynamic system libraries but I'm not in a position to offer support for local deployment on arbitrary Linux systems with arbitrarily-different dynamic libs.
What I
can offer is a standalone deployment script using Vagrant (for an optional VM-based build) and ansible provisioning. Ansible is a Python+YAML devops tool which scripts the d/l+compile sequence to either localhost or a Vagrant VM using standard
apt-get install to provision the host appropriately to the specific Linux distro and version (g++, Qt, openssl, miniupnpc, qrencode, etc).
Even if folks don't want to go as far as a VM build, the Ansible “playbook” spells out each step in excruciating detail, f'rinstance this stanza is from the companion MXE-compile-Slimcoin playbook (step-by-step cross-compile build from source on a VM for increased peace-of-mind) that retrieves Qt sources, nukes the mysql references and compiles:
---
- name: remove mysqllib from Qt5 compilation
action: shell cd /mnt/mxe; grep -v -- '-mysql' src/qtbase.mk | sed -e 's/libmysqlclient //' > /tmp/foo; mv /tmp/foo src/qtbase.mk;
- name: compile Qt5
action: shell cd /mnt/mxe; make MXE_TARGETS="i686-w64-mingw32.static" qttools
register: qtreport
- debug:
msg: '{{ qtreport }}'
This is just an illustrative example in which I tested my hypothesis that the mysql references could be relatively trivially removed from the standard MXE cross-compile build were it to prove desirable.
(And yup, it did run all the way through and created a Windows binary from freshly-compiled libs but I admit to not having the patience to wait for the emulated binary to read the blockchain+index. Perhaps I'll let it play out sometime over the w/e while Ngaio and I are enjoying re-watching John Carpenter's much-overlooked 1974 directorial debut film Dark Star, recently
re-posted to youtube in good-quality form.)
Cheers
Graham
