Closed Himan2001 closed 6 years ago
EmberCoin
commented
6 years ago I have replaced the version in the v1.1.5.1 with a much more secure version. Statically linked, Hardened (ASLR and Non-executable stack), Boost v1.65.1, LibreSSL. Let me know how that works for you. I'll be watching my own test build and operating version on my vps closely to make sure it works.
Himan2001
commented
6 years ago I work with your latest fixes on linux for now. still 200% load (2cpu) - but compiling was more sucessfull.
after i see what you changed for windows, here are my next suggestions:
With your latest switches to latest boost and ssl-support, i see that there is now a very big difference between the usual linux and windows builds....
I will remind you, that a lot of peoples uses the linux-makefile, and without specific variables, linux build usualy build with boost_1.58 and libdb5.3 on ubuntu 16.04, on ubuntu 14.04, lib4.8 and a much older boost!
Modifying now your codebase for the very latest boost will result most likeley in compiler errors for older (default distro) versions of boost. The result (without a more updated documentation) will be try&error by much users to self-build boost from scratch. (Usualy without all the small patches, that mxe and other scripts mostly include!) Without enough knowledge how to self compile boost, users must figure out, how to build static libs and how to set the non-standard variables for this boost-versions. (etc. etc. etc.....)
I HIGHLY suggest, to make it easier to have windows and linux nearly completly in sync by switching over to the "depends" directory, which is used on latest bitcore and btggold core. A short readme-update and a hint how to use the "--prefix" variable in an new configure script makes it complete. So github-users simply "make" the depends before they compile the main-code.
Using this way, user can build minimal mingw-compiler from latest mxe.cc in 32 or 64bit version, and all other needed libs for linux, windows and mac are part of the "depends" preprocessing part. Special customisations and needed flags you can better set in this framework. (Or the user uses the distro mingw-versions for 32 or 64Bit, which goes faster as self-build the cross-enviroment with mxe.)
By using this method you can make sure, that all libs are build with static-support, ready for any usual or unusual cross-compiler and the results are more predictable ;-)
Himan2001
commented
6 years ago One more thing about the actual problems with unfixed errors and the high cpu-load:
Replacing more libs at once without solving the existing errors can bring you new multipoint of failures. I know often a problem is fixed, by using a newer lib - about the high cpu-load there is no lib-problem - this problem existst since a longer time. x100% cpu-load, when mining = off, staking = off and no actual tx queues from the network has more todo with an eventualy accidently swapped codeline in a loop ? a wrong interpreted true or false compare, etc. The simple question is: When there are NO JOBS for the miner or staker - what is calculated then ? 0 Output transactions ? Dummy running kernel-threads ?
EmberCoin
commented
6 years ago It's very likely a thread pinning CPU for "no reason", I know that the RPC server adds another cpu core to pinning. I have to valgrind to find excatly where it is and determine why.
EmberCoin
commented
6 years ago Marking this as closed for now. I agree with what you've said regarding the "usual options" and the makefile. The options I've changed are not different from the current latest revision's windows version. Nevertheless I will take what you've said under advisement. We need better documentation on how we built.
The precompiled Linux-Binary is a very bad choice for many peoples...
Reason:
Acording to the "usual" Ubuntu 14.04 and 16.04 Mining-Users, it makes only sense, to use the RELEASE=1 or STATIC=1 option for compiling!
Doing so, you always include the libdb and boost related things in a more useful way. The resulting Binary will then run on nearly all existing Linux-Versions.