You're using a daemon that was built on another system.. Don't do that.
Why not to do that? Is it will create soft fork?
Topic: Trouble with running Daemon on Seed Node (Read 517 times)
Why not to do that? Is it will create soft fork?
Hello,
Your workflow should include building a static version of the coin daemon for the seednode and hopefully have STATIC=1, PIE=1 and USE_UPNP:=- in the makefile.unix file on a hardened toolchain.
This will help you to ensure all of the dependencies are statically linked so that your package manager doesn't end up leaving you in a position down the road where a missing file breaks the binary's ability to execute.
Run ' ldd ' on the executable you have to see how it is dynamically linked at present and you will know all of the required files at runtime.
Your goal should be to satisfy all of the dependencies at build time such that the only runtime dependency is the coin daemon's executable. This is easily accomplished with static libraries for the dependencies and a statically linked coin daemon executable.
In other words, you have some work to do, preparing a proper toolchain on the target system (seednode) and some compiling to perform.
You could conceptually make a build box where you do all of the work there and then have the seednode be a paired down version of it with just the bare essentials.
Just don't fall into the trap of having the coin daemon compiled on a completely different system with an entirely different toolchain, where there is great variance between the GNU libraries and other dependencies and then go to run the coin daemon by copying it onto another system.
Your ideal situation is a build box which is nearly identical to the seednode with the exception of having the additional sources available and additional libraries required for compilation.
If you compile with STATIC=1 within makefile.unix, you will not need to have the shared object files on the seednode.
Best Regards,
-Chicago
Your workflow should include building a static version of the coin daemon for the seednode and hopefully have STATIC=1, PIE=1 and USE_UPNP:=- in the makefile.unix file on a hardened toolchain.
This will help you to ensure all of the dependencies are statically linked so that your package manager doesn't end up leaving you in a position down the road where a missing file breaks the binary's ability to execute.
Run ' ldd ' on the executable you have to see how it is dynamically linked at present and you will know all of the required files at runtime.
Your goal should be to satisfy all of the dependencies at build time such that the only runtime dependency is the coin daemon's executable. This is easily accomplished with static libraries for the dependencies and a statically linked coin daemon executable.
In other words, you have some work to do, preparing a proper toolchain on the target system (seednode) and some compiling to perform.
You could conceptually make a build box where you do all of the work there and then have the seednode be a paired down version of it with just the bare essentials.
Just don't fall into the trap of having the coin daemon compiled on a completely different system with an entirely different toolchain, where there is great variance between the GNU libraries and other dependencies and then go to run the coin daemon by copying it onto another system.
Your ideal situation is a build box which is nearly identical to the seednode with the exception of having the additional sources available and additional libraries required for compilation.
If you compile with STATIC=1 within makefile.unix, you will not need to have the shared object files on the seednode.
Best Regards,
-Chicago
Could you elaborate on using a daemon such as that? Thanks
You're using a daemon that was built on another system.. Don't do that.
Running a litecoin POW clone, coin is fine. Problem is the daemon and trying to set up a seed node on linux. When i run mycoinnamd, i get the error:
error while loading shared libraries: libboost_program_options.so.1.54.0: cannot open shared object file: no such file or directory exists.
When i went to install dependencies, Boost 1.58 was automatically installed. I tried purging and uninstalling boost, downloading boost 1.54, extracting and installing and building it, but to no avail.
Is there a way for me to workaround this? Thanks
error while loading shared libraries: libboost_program_options.so.1.54.0: cannot open shared object file: no such file or directory exists.
When i went to install dependencies, Boost 1.58 was automatically installed. I tried purging and uninstalling boost, downloading boost 1.54, extracting and installing and building it, but to no avail.
Is there a way for me to workaround this? Thanks
Jump to: