Yesterday I built trb on my local computer running CentOS 6.9. I imagine I saved a bit of time from already having keccak V setup. The only dependency from the list on the bitcoin foundation's website I was missing was "bc."1
After grabbing the vpatches from the foundation's website I also pulled in two other vpatches written by jfw, one that provides an improved way to get/send rawtx's and another that fixes up the bitcoind build process in various ways. The commands to grab the patches and seals:
wget http://fixpoint.welshcomputing.com/v/bitcoin/bitcoin_rawtx_get_send.vpatch
wget http://fixpoint.welshcomputing.com/v/bitcoin/bitcoin_system_compiler.vpatch
wget http://fixpoint.welshcomputing.com/v/bitcoin/bitcoin_rawtx_get_send.vpatch.jfw.sig
wget http://fixpoint.welshcomputing.com/v/bitcoin/bitcoin_system_compiler.vpatch.jfw.sig
After a successful press, I ran into a couple of errors when trying to build the beast that is trb. The first one was some error related to my LD_LIBRARY_PATH variable. (UPDATE: As jfw pointed out in the comments, this error was received when I tried to do the build for the first time, without his system_compiler patch.)
You seem to have the current working directory in your
LD_LIBRARY_PATH environment variable. This doesn't work.
make[2]: *** [core-dependencies] Error 1
make[2]: Leaving directory `/home/whaack/v/trb054/bitcoin/build/buildroot-2015.05'
make[1]: *** [buildroot-2015.05] Error 2
make[1]: Leaving directory `/home/whaack/v/trb054/bitcoin/build'
make: *** [build] Error 2
I updated my environment by running:
LD_LIBRARY_PATH="";
in my terminal.
The next problem I ran into was building Boost. I caught the issue because I actually stared at the screen and watched all that compiler spew. Python errors flowed in front of my eyes, and I figured that the problem must be related to the fact that the native python on CentOS 6.9 is python 2.6.6 rather than python 2.7.x.
Getting my environment to use python 2.7.x instead of python 2.6.6 was a little bit tricky. Apparently you cannot update the native python without putting your OS in danger. So you need to install this program scl as well as python27 through yum and then use scl to start a temporary environment that has python pointed at python27. In this environment you build bitcoind.
scl enable python27 bash
cd ~/v/trb054/bitcoin/
make ONLINE=1
- I also had to downgrade my gpg from 2.X to 1.4.23, as well as tweak my path so that my gcc was 4.4.7. (Previously my gcc was pointed to some gcc 8.x used by a 2019 version of GNAT.) [↩]
From a discussion in #therealbitcoin and rereading jfw's article on the build system overhaul for bitcoind, I realized that I had missed the point where the operator of jfw's build overhaul vpatch is expected to have a "sane environment." My local centOS 6.9 does not make the cut. Without jfw's patch I may have been able to successfully build boost without having to switch my python version.
http://logs.nosuchlabs.com/log/therealbitcoin/2020-07-08#1000784
But you couldn't have been running with my system_compiler patch in this case, otherwise there wouldn't be buildroot messages, no?
The "sane environment required" does seem a bit of a cop-out. One could make a list of systems know to work by starting from fresh installs.
@Jacob Welsh.
Ah yes. Thank you for pointing this out, the first error I received related to LD_LIBRARY_PATH was when I tried to build trb without your two patches.
Thanks for clarifying. I'll note my Gales bootstrap procedure establishes a minimal process environment, inheriting external variables by whitelist only, and thus wouldn't trip up on weird LD_LIBRARY_PATH and such. Ofc it's not a drop-in replacement for 'rotor' at present, but that might make an interesting project, perhaps once Gales itself is a bit more V conforming.
When I get to doing a full TRB fetch & build script I might see if I can reproduce the python thing on a CentOS 6, as I'd rather it work if the fix is simple enough. Ultimately though this will be a losing battle at least until the excess autoconf DWIMism is removed from those Big Three dependencies - preferably by integrating the necessary parts into the TRB tree proper.
So in the end did you build trb with rotor ?
I actually wound up "successfully" building trb with jfw's patch on centos 6.9. From my understanding, since I built on a potentially "dirty" OS, my trb may have a dependency whose binary-in-use differs from the expected ones that come from either building w/ rotor or building on Gales w/ jfw's patch.