Bitcoin Forum

Does anyone have the binary?

Which version? I haven't tried to build any yet, but after building on a few different distro so far, kind of got the process down pat.  ;)

I've got a CentOS 5.5 machine I could experiment with.

[foo@bar ~]# cat /etc/issue
CentOS release 5.5 (Final)

[foo@bar ~]# uname -a
Linux foo.bar 2.6.18-194.3.1.el5.028stab069.6 #1 SMP Wed May 26 18:31:05 MSD 2010 i686 i686 i386 GNU/Linux

Cool, we could both use a build then  ;)

My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?

Anyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon.

Apparently, even after copying over the header file; those libraries are disabled, grrrr.

Guess I'll have to hack one together  :'(

Ok, got around the encryption issue (guess it's never going to be part of the Cent OS library since they don't use that part of openssl), legal issues aside, just left with the DB issues during compile, so I'll need to compile a db4.7 version and hopefully we'll have a test build here soon.

Yes, it's not that simple - otherwise I could have compiled it myself.

1) In CentOS OpenSSL rpm elliptic curves cryptography is disabled, so you have to build OpenSSL yourself.
2)  CentOS Boost-devel RPM is outdated and missing a lot of things, so you have to build Boost yourself too.
3) CentOS WxWidgets RPM is outdated so you have to build it yourself too. And its build requires more than 256 mb ram. Satoshi improved bitcoind so doesn't require wxWidgets any more, but I'm not sure whether that patch is in 0.3.7 or whatever sources you are building.

I've been able to get around all of those, I'm actually stuck at the DB4.7 stuff.

I build it directly from the source and during the compile I get an error:
I checked the header file, I think there is a syntax error, but not sure.

Any suggestions?

This is the block of code it stalls at, the class is defined at the top of the file, so I'm not sure why it hangs at that error without digging through all the Berkeley DB code. I don't want to go to a newer version of the DB if it's going to mess with everyone's BitCoin database that uses this build.

I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk. :-\

Yeah, the bitcoind build gets around any errors for those, but I still get stuck at the DB error.  :(

Just for kicks, tried to compile with DB4.8 got the same error, LOL (the line number was slightly different, but at the same class)

Didn't get this on other Distros, might be a CentOS related error, but not sure why.

Yes, ecdsa.h is considered patent-encumbered, so Red Hat and other distros turn off ec-dsa.

Yes, Virginia, this means that bitcoin potentially has patent problems.

I'm probably going to load up a virtual machine of CentOS 5.5 and work with that. I've really barfed up the server I was experimenting on trying make it build the binary, LOL.

I urge you not to use BDB 4.8.  The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.

Ok, conquered the DB issue after pestering an Oracle developer all day  :P

When you compile DB 4.7.25, you have to use an extra config command or else the compile will be missing those vital header files (why???)

Anyway, here is what it was
When you compile the source, this fixes the DB compiling related errors.

Ah, crap. I totally forgot about that extra flag. I knew about that before from Lazslo's Linux Build Document. Sorry about that. Get a working build up and running and you'll definitely be getting some BTC from me.  ;D

Oh, but there's more!  :o

Even after I did that, I couldn't get it to compile due to linking errors. I was able to get a solid compile of bitcoind though, this is the extra steps it took.

After compiling and installing the BerkeleyDB4.7, you need to add it's include path to the makefile.unix

Add -I"/usr/local/BerkeleyDB.4.7/include"

Then you need to copy all the libraries from "/usr/local/BerkeleyDB.4.7/lib" to "/usr/lib"
BUT WAIT, there's MORE!  ???

Yes, and if that was not annoying enough, now it will fail to compile because of an OpenSSL error, Grrrrr..

Now you must copy libcrypto.a and libssl.a from "/usr/local/ssl/lib" to "/usr/lib"

Yes, those can be linked, but I got tired of chasing down compiler errors, was easier to just copy them.  ::)

After all of that, then you should be able to compile a bitcoind binary.

I'm testing it now, seems to be working just fine. Downloading blocks and such. When it finishes, I'll experiment with some coin generation and coin transfer.

I'm still caught on the GUI client compile, currently hangs at
If anyone is good with Google, let me know.  ;)

I've posted the binary up here (32 bit only - bitcoind):
Click Here (http://knightmb.dyndns.org/files/bitcoin/custom%20builds/x86/CentOS%205.5/)

There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)

Will probably tackle the GUI client build another day, this one wore me out. Donate some BTC to my sig if you are feeling generous  ;)

I'd rather you didn't make a build of the 1000 node connecting version available.  It won't take very many people running that before we have to make another release just to limit the incoming connections.

I appreciate your concern; the current release version already limits connections to 8, this one won't establish hundreds of connections to a single client or node, it's just modified to allow hundreds of connections back to it from independent clients. I figured since I have the CPU and bandwidth horsepower, why not put it to good use for Bitcoin?

I must have REALLY screwed up my CentOS 5.5 box. This is what I'm getting with my build from the trunk and your build:


Any Ideas?

I've been running mine since I made the first post about where to download it.

Everything seems to be fine and the bitcoind is using 100% doing coin generation at the lowest prioirty from when I checked top

From what I can tell on your output, it seems to be hung at that block for some reason. When you stop the daemon and restart it, does it continue on then?

If you want, you can try a direct connect mine with ./bitcoind -server -connect=12.53.130.10 to see if it's a build thing.

You'd rather publish this link. It's much more useful as you happen to have x64 builds too. My x64 build was outdated

http://knightmb.dyndns.org/files/bitcoin/custom%20builds/

Upd: Yeah it works on my x86 box! You definitely deserve a donation once that box generates its first coins.
Upd2: x64 folder is empty :-\ I can give you non-root access to Centos 5.4 x64 if you wish. PM me your SSH2 public key.

Yeah, been moving around folders to try and organize things. I have about a dozen virtual box now of many different distro so as I get time, I'll compile other releases and label them properly. I don't have a x64 build yet because I haven't built a x64 virtual box with Centos 5.5 yet  ;D

I did notice it works with CentOS 5.4, so I fired up an Amazon EC2 instance running CentOS 5.4 on 16 cores and loaded it up. After it downloaded blocks, it starting churning away on 16 cores, but only managed about 8,800 khash/s, kind of disappointing for an EC2 instance.

If I stop and restart the daemon, it will continue for the next 500 blocks. At that point it will once again lock up, even though the program isn't crashing a thread must be.

Just connected to your node and it did the same thing. Pulls down the next 500 blocks really fast and then locks up. Thoughts?

I've compiled an x86 version with the 0.3.8 source, can you try using that one? If you already have it, the only thing I can think of is have it start from the beginning by deleting the blocks and let it start fresh in case something was corrupted in the beginning.

Yep, that's the one I downloaded and am running as of last night. That has the same problems for my system as my build one so I'm guessing it's my env. Trying a full cleanup and re-downloaded right now.


Update: It still fails to download correctly. Time for a fresh re-image of this box. Oh well.

1) It? I couldn't run your x86 build on 5.4 x64.

2) How much per month for that instance? EC2 is a very expensive provider for a very big sites that can afford paying good money for good infrastructure. By "infrastructure" I mean their elastic computing API, load balancing, storage and content delivery services. My current record with cheap VPS is 3100 khashes/sec for $5/mo.

Well, you could cheat I guess and copy the full blocks from another machine if you have one (Linux box) to see if it hangs or if it can continue from that point.

That is really strange though, if anything the CentOS build downloads blocks faster than anything I've seen yet. I can download the entire block chain in a few minutes with this build.

It should run, I was able to run it on their (cc1.x4xlarge, 23GB) CentOS Cluster even though it's not a x64 build, the x86 still worked for me. I didn't even need to install the full bitcoin, I just uploaded the bitcoind and ran it right from root  ;D

It was very expensive, $1.60/hour per "Cluster Compute Quadruple Extra Large" basically.

I only ran a 1 hour instance just to see how it performed (too expensive to be practical) and I was checking the debug.log file to see what it was recording for khash/s.

I wonder if a x64 build would run faster on that cluster than the x86 build?  ???

Downloading the x64 DVD right now via BitTorrent, should be able to get a virtual box of this up within the day. Should get a x64 compile then for bitcoind when it's all done, I'm curious myself to see how it runs.

Which VPS provider?

Any chance for 0.3.8.1 binary?

Does anyone have 0.3.10 binary for CentOS (either 64 or 32)?

I've got the bitcoind binary, but not a GUI build.

bitcoind is what I need. Have not seen Linux GUI since 2004 :-\

Hi, I guess there's still a need for precompiled binaries on CentOS (32 bits) for bitcoin or at least bitcoind.

When I run the one provided by bitcoin 0.3.24, I get the following errors:


Any clue on how to get it working?

Yep, I run into this too.  Problem is that CentOS is built against glibc <= 2.5.  No way to update to later, your OS wouldn't work.

knightmb has a share of CentOS builds but his latest is 0.3.12 - much older than the current 0.3.24.  I can't figure out how to get it to build, there are too many problems in the dependency tree.

knightmb, can you post post how you got this to build?  I am willing to take up the torch of keeping up to date CentOS builds, if you can give me a kick start.

Scratch that, I got it.

Happy to help others, but the instructions are a little long to take the time to post here for now.

We had to build our own Bitcoin 0.3.22 binary for CentOS 5.5 a few weeks ago, for our casino's entry into the bitcoin market (which is imminent  ;D). I don't mind sharing it, as I sure as hell wouldn't ever want to do it again. There were some instructions for a makefile floating around the web; they were basically wrong. Anyway, I did get it figured out; I put up a tarball here of just the binary. To use this, basically place it in your web hierarchy (outside the public directory) and run it. It'll create a .bitcoin directory in the root directory of the user that runs it. You'll then need to put a bitcoin.conf file into that before properly using it:

https://strikesapphire.com/bitcoind.0.3.22.bin.tar.gz   -----Small, works wonders, though already slightly outdated  :-\

And now here's a tarball with everything you would need to build it:

https://strikesapphire.com/bitcoin.all.centos55.tar.gz      ----Warning: 165 Mb.

The "everything" file is pretty big. It includes a working bitcoind binary, as well as a proper CentOS makefile under Trunk/ and also builds of BerkeleyDB, boost and openSSL which have to be available if you want to use the makefile to compile a newer version. Should be plug and play to throw a new version at it, but please don't ask me how to do anything with this. It took a whole bunch of hours hacking away at it until it worked, and frankly, I was kind of wasted and don't remember what I did or didn't do. Nor was it fun. I'm hoping the BTC crew will offer a working CentOS distribution for future releases to make life easy on people who just want to use it, not fuxor around with some dude's broken PDF makefile for 6 hours. A lot of people with shopping carts run CentOS-based systems.

Just a warning about 0.3.22 on CentOS: If you run it for two weeks, you'll find it sucking up about 25% of your system memory. Just kill it and restart. There's a leak in there somewhere.

Yep. I just stored a copy of the command history and will clean it up later. Might make an installer script to make things easy.


Running 0.3.25 straight from git... will let you know if I see any leaks.

Thanks for posting the binary - will certainly help others get up and running faster.  This was certainly a journey.

I'm in the middle of making a "proper" CentOS build, including all necessary dependencies. Once complete it will be in a proper yum repository so you can just yum install and yum update it like everything else on your system. As several people have noted, it's harder than it looks, and combined with the necessity of keeping it separated from the existing system libraries and packaged for distribution in a yum repository, it's going slower than I would like. But once I'm done with this pass it will be about 95% automated, (the manual part being downloading the new source code from SF) so I can have new versions of Bitcoin out within hours of their official release.

I already uploaded my CentOS 5.6 x86_64 0.3.24 static build to the following thread.

http://forum.bitcoin.org/index.php?topic=27352.0

I've got the environment for it now so I was going to continue to release 5.6 x86_64 static builds as new stable versions are released.

An easy way around the problem is compile bitcoind under debian statically, and then it will run under Cent OS without problems.
However that is easy for the command line version, it is very difficult for the gui.
To get it to compile statically you have to make sure that under debian you have installed the developer libraries, most of those libraries are not installed by default, under ubuntu it is the same as debian.
By developer library I mean those libraries that end in .a for example libxxx.a, the ones that en in .so are runtime libraries.