Pages:
Author

Topic: Bitcoind x86 binary for CentOS - page 2. (Read 18288 times)

member
Activity: 61
Merit: 10
August 04, 2010, 09:54:41 AM
#26
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.

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?
sr. member
Activity: 308
Merit: 256
August 04, 2010, 09:44:20 AM
#25
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 Undecided 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  Grin

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.
sr. member
Activity: 252
Merit: 250
August 04, 2010, 06:09:26 AM
#24
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 Undecided I can give you non-root access to Centos 5.4 x64 if you wish. PM me your SSH2 public key.
sr. member
Activity: 308
Merit: 256
August 03, 2010, 11:15:46 PM
#23
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
Code:
knightmb@serverfarm528 32]$ ./bitcoind getinfo
{
    "balance" : 0.000000000000000,
    "blocks" : 72169,
    "connections" : 329,
    "proxy" : "",
    "generate" : true,
    "genproclimit" : -1,
    "difficulty" : 244.2132230923753
}

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.
member
Activity: 61
Merit: 10
August 03, 2010, 09:22:34 PM
#22
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:
Code:
Tue Aug  3 15:24:07 CDT 2010
[myles@kappa ~]$ ./bitcoind getinfo
{
    "balance" : 0.000000000000000,
    "blocks" : 3095,
    "connections" : 5,
    "proxy" : "",
    "generate" : true,
    "genproclimit" : -1,
    "difficulty" : 1.000000000000000
}
[myles@kappa ~]$ date
Tue Aug  3 15:28:53 CDT 2010
[myles@kappa ~]$ ./bitcoind getinfo
{
    "balance" : 0.000000000000000,
    "blocks" : 3095,
    "connections" : 5,
    "proxy" : "",
    "generate" : true,
    "genproclimit" : -1,
    "difficulty" : 1.000000000000000
}


Any Ideas?
sr. member
Activity: 308
Merit: 256
August 03, 2010, 08:25:42 PM
#21
There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
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?
founder
Activity: 364
Merit: 6472
August 03, 2010, 08:09:32 PM
#20
There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
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.
sr. member
Activity: 308
Merit: 256
August 03, 2010, 07:46:46 PM
#19
I've posted the binary up here (32 bit only - bitcoind):
Click Here

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  Wink
sr. member
Activity: 308
Merit: 256
August 03, 2010, 07:17:01 PM
#18
Oh, but there's more!  Shocked

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!  Huh

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.  Roll Eyes

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
Code:
/usr/bin/ld: cannot find -lSM
If anyone is good with Google, let me know.  Wink
member
Activity: 61
Merit: 10
August 03, 2010, 06:51:13 PM
#17
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.  Grin
sr. member
Activity: 308
Merit: 256
August 03, 2010, 06:11:05 PM
#16
Ok, conquered the DB issue after pestering an Oracle developer all day  Tongue

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
Code:
../dist/configure --enable-cxx
make
When you compile the source, this fixes the DB compiling related errors.
founder
Activity: 364
Merit: 6472
August 03, 2010, 05:05:08 PM
#15
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. Undecided
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.

sr. member
Activity: 308
Merit: 256
August 03, 2010, 02:53:37 PM
#14
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. Undecided
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.
legendary
Activity: 1596
Merit: 1091
August 03, 2010, 02:10:24 PM
#13
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.

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.
sr. member
Activity: 308
Merit: 256
August 03, 2010, 01:59:12 PM
#12
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.
sr. member
Activity: 308
Merit: 256
August 03, 2010, 01:32:06 PM
#11
{snip} 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.
Yeah, the bitcoind build gets around any errors for those, but I still get stuck at the DB error.  Sad
member
Activity: 61
Merit: 10
August 03, 2010, 01:30:37 PM
#10
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. Undecided
sr. member
Activity: 308
Merit: 256
August 03, 2010, 01:29:28 PM
#9
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:
Code:
db_cxx.h:1083: error: expected class-name before ‘{’ token
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.
Code:
// Almost any error in the DB library throws a DbException.
// Every exception should be considered an abnormality
// (e.g. bug, misuse of DB, file system error).
//
class _exported DbException : public __DB_STD(exception)
{
public:
virtual ~DbException() throw();
DbException(int err);
DbException(const char *description);
DbException(const char *description, int err);
DbException(const char *prefix, const char *description, int err);
int get_errno() const;
virtual const char *what() const throw();
DbEnv *get_env() const;
void set_env(DbEnv *dbenv);

DbException(const DbException &);
DbException &operator = (const DbException &);

private:
void describe(const char *prefix, const char *description);

char *what_;
int err_;                   // errno
DbEnv *dbenv_;
};
sr. member
Activity: 252
Merit: 250
August 03, 2010, 01:21:58 PM
#8
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.
sr. member
Activity: 308
Merit: 256
August 03, 2010, 12:32:57 PM
#7
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.
Pages:
Jump to: