I want to build bitcoind on linux

[coinrevo]

It seems the documentation for building bitcoind on linux is stale? Somebody outside the dev team must be able to keep this info up to date? If somebody has a working script on Ubuntu 13 please let me know, as I'm rather tired of this.

I've spend a lot of time gathering a proper build script, but I now I find with 0.8 all of this is irrelevant because of switch to levelDB.

Here the current doc which refers to a berkeleyDB 4.8 build, which I understand is obsolete:
https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

With the following added packages I'm able to build, but without BerkeleyDB (adding that as a flag when configure make).

apt-get install -y libdb++-dev
apt-get install -y libprotobuf-dev
apt-get install -y alien

[flatfly]

I have some pretty nice build instructions in my notes at home, but I'm travelling during this weekend.
Hopefully somebody else will help out in the meantime.

[coinrevo]

If we want to have people building bitcoin from source and running their own nodes, way to go on the documentation. What are all the bitcoin zillionaires doing in their free time?

[NoahBuscher]

Like the above reply said, the official docs are a great place to start, though I'm finding that StackOverflow and other Bitcoin developer's blogs are much more helpful as I get into things like compiler errors (damn Windows).

[Cryddit]

I've got Bitcoind compiling on linux (Debian, to be exact).

The procedure, if you have all the things it depends on, is: 

In the top-level directory of the repository, there is a file 'autogen.sh' - it's executable and you run it.  This gathers all kinds of information about your system that is relevant to the extended set of things it depends on. It makes a file named 'configure' in the same directory using all of this information. (it makes several other things too, but 'configure' is the next thing you need to run to make the build work.) 

Next, you run 'configure' -- it creates makefiles and sets environment variables and sets configuration flags for the libraries you depend on. 

Finally, you run 'make' in the top-level directory, and go get coffee or whatever; depending on your machine the first build can take anywhere from five to fifteen minutes.  It's usually faster after that, except if you change anything in the header files.

After you have run 'autogen.sh' and 'configure' you shouldn't need to run them every time you build, unless the info they depend on changes. Which it will, if you alter your system configuration or, sometimes, if you update software, but not every time you compile.

Some Gotchas:  If you're on Debian or Ubuntu, you probably have a more recent version of Berkeley db than the one that's required.  4.9 is the last version compatible with the Bitcoin sources.  If your system has automatically upgraded to 5.1, you'll need to go to the software sources and install the individual packages of 4.9.  Don't worry, all the necessary 4.9 packages can exist on the same machine as the corresponding 5.1 packages.  Don't install any of the 4.9 "-dev" packages; they conflict with the corresponding 5.1 "-dev" packages. And don't install the 4.9 meta-package; if you don't install the individual 4.9 components by hand, they'll just disappear next time you do software update - because there's a more recent version now and your system is stupidly trying to help.

I do not remember the whole list of dependencies. You will need at least build-essential, libboost-all-dev, libcurl4-openssl-dev, git, and qt-sdk in addition to the Berkeleydb stuff.  But I got everything on that list that I didn't already have when I started working with Bitcoin source, and I remember I still had to go back to the software manager several times to get more stuff, or other versions of stuff.

Now, this procedure will build bitcoind and bitcoin.cli in the 'src' directory, one level below where the 'autogen.sh', 'configure', and 'make' commands were created.  It does not build the QT wallet. 

I am still stumped about how to build the QT wallet.  There's a makefile in the src/qt subdirectory, but the 'recursive make' doesn't run it when doing the above, and when I run make in that directory, it just gives an error message that says it can't work because the current directory is a directory.  I say that isn't a good excuse, but the makefile is pure gobbledegook as compared to one written by hand that names actual files and gives specific straightforward  directions to make each one.  So I've got to wade through a lot of template crap to figure out what's going wrong.

[Cryddit]

Oh, and I forgot to mention: if you habitually develop in emacs, as I do, and you want to actually work with the sources, you'll want to start out by doing 'astyle -A2 -s2' on all of the source files to put them in the indent and brace style you're used to. Of course, you may have to 'sudo apt-get astyle' first.

[justusranvier]

The easiest way to build things on Linux is to run Gentoo.

[Cryddit]

Okay, I at least made some progress on the wallet thing.  I needed to get protobuf and libqrencode; these are dependencies not apparently shared by the rest of the project.  Once I got those (in addition to what I already had) the build system is at least attempting to make the qt wallet. 

However, when it does, I still get this lovely message. 

../..: Is a directory.  Stop.

Um, yes.  What the hell did the make system expect it to be?  Every directory on my computer is a directory!

[super3]

I was rewriting the Bitcoin linux documentation for the building 2 days ago, but stuck with all the new libs and versions. If someone has a working guide or figures it out, let me know. Will save some time troubleshooting it myself.

[coinrevo]

Thanks for the responses. As I mentioned above the documentation in github is not accurate and all the stackexchange posts are out of date because of LevelDB. Is LevelDB optional? the database backend depedency was reason for the March bug, so the build management could be improved as far as I can see.
 
I'm going to write a build script myself then if there aren't any. Blog posts and threads are not good way to manage the dependencies. At least there should a build script for a couple of basic distros.

BlueMatt publishes these PPA's. It would be good to have builds scripts to verify instead of using a PPA.

bitcoin - 0.8.6-saucy1    (changes file)    bluematt    2013-12-13    Published    Saucy    Utils    All builds were built successfully.
bitcoin - 0.8.6-raring1    (changes file)    bluematt    2013-12-13    Published    Raring    Utils    All builds were built successfully.
bitcoin - 0.8.6-quantal1    (changes file)    bluematt    2013-12-13    Published    Quantal    Utils    All builds were built successfully.
bitcoin - 0.8.6-precise1    (changes file)    bluematt    2013-12-13    Published    Precise    Utils    All builds were built successfully.
bitcoin - 0.8.6-lucid1

I've tested on fedora19, which does not work due to ECC licenses.
I went through all the docs, blogposts, etc. The problem is they are not up to date.

[Cryddit]

It's my opinion that there are way too many dependencies in the Bitcoin build. 

I get that it's convenient for development and avoids certain classes of bugs because the bugs are already worked out of some of these libraries, but... in the long run a big family of dependencies makes something fragile.  It may or may not be okay with any change in any of them.  And that's really kind of unacceptable when people are depending on this for so much value. 

I've had to learn Boost specifically to work on these sources, and mostly I'm aghast at the wasted resources, excessively long compile times, failure to use the standard libraries where they are adequate, incompatibility with C++11, etc.  Boost is convenient for development, but it's a pig and it's holding the project back from being compatible with the latest version of the language itself.  It's not worth my time -- yet -- to de-Boost the sources, but it's on my list of things to do as I develop an altcoin. 

As for others; Remote procedure calls are a good thing.  JSON is a good thing.  But I hate the JSON_spirit libraries.  Too much templatization, too much obfuscation.  Nobody can just dive into it and fix something; you have to spend a week figuring out how the thing you want to fix affects and is affected by everything else first.  I get that the Bitcoin project itself hasn't had to look at it for many builds so it's not particularly inconvenient for them; but if you're trying to adapt the sources to do something different (particularly, to replace something that's serialized in the protocols and files with something that isn't what the spirit libraries natively understand, without screwing up the rest of the serialized stuff around it), JSON_spirit is like wearing chains on your wrists. 

And then there's the database thing.  Aside from being a moving target which the build process isn't compatible with the new versions of, it's another pig.  Besides that, the only excuse for putting up with a database is if you need to use the database to share information with other applications, and if you've already got JSON remote calls you don't need it for that.  Besides, you have to be very very careful what you put into a database, because you have to regard that stuff as being shared by default, and stuff *NOT* being shared is pretty crucial to security.  So I think the database dependency needs to be ripped out too. 

Now these are all my opinions, coming at this from the point of view of an altcoin developer.  But with the heavy templatization, the clumsy and inefficient dependencies, the incompatibilities with later versions, etc etc, the Bitcoin sources are aggressively difficult to modify and adapt, and require a full-time developer just to keep up with the changes in all the crap its dependent on.

[NoahBuscher]

It's my opinion that there are way too many dependencies in the Bitcoin build. 

Tell me about it! I'm trying to build on Windows, and I've went through about, oh say, a dozen guides and still no luck, and the official docs that ship with Bitcoin tell more or less nothing, especially when you're trying to build a modded version.

[coinrevo]

I'm glad I'm not alone with my opinions. I'll admit I'm biased against C++/boost, but heck, I can't even get a proper exception message and get this thing to build, without requiring a long research project. I have no intention of learning boost just to build the source. And the idea is everyone would build from source?!

When was boost introduced? This kind of build management is much to fragile to depend on IMO.

[super3]

Thanks for the responses. As I mentioned above the documentation in github is not accurate and all the stackexchange posts are out of date because of LevelDB. Is LevelDB optional? the database backend depedency was reason for the March bug, so the build management could be improved as far as I can see.
 
I'm going to write a build script myself then if there aren't any. Blog posts and threads are not good way to manage the dependencies. At least there should a build script for a couple of basic distros.

BlueMatt publishes these PPA's. It would be good to have builds scripts to verify instead of using a PPA.

bitcoin - 0.8.6-saucy1    (changes file)    bluematt    2013-12-13    Published    Saucy    Utils    All builds were built successfully.
bitcoin - 0.8.6-raring1    (changes file)    bluematt    2013-12-13    Published    Raring    Utils    All builds were built successfully.
bitcoin - 0.8.6-quantal1    (changes file)    bluematt    2013-12-13    Published    Quantal    Utils    All builds were built successfully.
bitcoin - 0.8.6-precise1    (changes file)    bluematt    2013-12-13    Published    Precise    Utils    All builds were built successfully.
bitcoin - 0.8.6-lucid1

I've tested on fedora19, which does not work due to ECC licenses.
I went through all the docs, blogposts, etc. The problem is they are not up to date.

I just bought coingen.io from him. So I have his windows build scripts. I'll look into making a one click build tool. People need to spend less time building and more time making stuff.

[coinrevo]

I don't understand what you're saying. building bitcoin is pretty basic stuff, and yet this is now a multi-day project just to get the build down on a standard distro. seriously... a buildscript should be helpful for the bitcoin ecosystem. people can build their own VM's / Servers images this way.

[super3]

I don't understand what you're saying. building bitcoin is pretty basic stuff, and yet this is now a multi-day project just to get the build down on a standard distro. seriously... a buildscript should be helpful for the bitcoin ecosystem. people can build their own VM's / Servers images this way.

It used to be pretty easy, but with the new libs/versions and no documentation its gotten pretty difficult. I've always opted for good docs, but no one seems to care.

[coinrevo]

That's not a good sign at all. I would have imagined at least 50-100 people providing some groundwork. But it seems its up to just a very small group of people. Is anyone even auditing the source code? Seriously. How should I be able, as someone not involved with core dev, to verify bitcoin does what its supposed to do, if basic documentation is not up to date. yes, devs don't care, for one they might be busy, but also I think this is not taken seriously enough. not good.

instead of building application ontop of bitcoin, I find myself in the position of debugging bitcoin, with vague error messages.

[Cryddit]

Okay, I got the qt-wallet figured out.  It was my mistake, of course.

I had replaced '$(TOPBUILDDIR)/src' with '../src' in a 'Makefile.am' in the qt directory (which was, by the way, literally true with respect to that directory) and the 'magic' applied to pathnames by autoreconf had transformed it into something silly. 

By the time it got through to make, 'make' thought I was telling it to *build* a directory.  And the error message was completely opaque because I hadn't *told* make what to build, instead hoping for autoconf to do that.

The moral of the story is, never attempt to use a relative path in a Makefile.am file.  Autoconf will mess it up.  Instead you MUST use opaque macros to name directories. 

[super3]

That's not a good sign at all. I would have imagined at least 50-100 people providing some groundwork. But it seems its up to just a very small group of people. Is anyone even auditing the source code? Seriously. How should I be able, as someone not involved with core dev, to verify bitcoin does what its supposed to do, if basic documentation is not up to date. yes, devs don't care, for one they might be busy, but also I think this is not taken seriously enough. not good.

instead of building application ontop of bitcoin, I find myself in the position of debugging bitcoin, with vague error messages.

You can see that there are 50-100 working on it http://bitcoin.org/en/development. You have to realize that Bitcoin is still pretty new and exciting. Almost like the Internet in the 90s. So basically we are at this stage:



Once I grab some funds from freelancing I'm going to lead a personal initiative called CoinDocs to completely revamp Bitcoin documentation. It needs to be fixed and now.