*** ALERT *** Upgrade to 0.3.6

[knightmb]

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

That's good to know, might just need to update mine, checking to see what versions I have currently installed.

[1713497296]

1713497296

[1713497296]

1713497296

[1713497296]

1713497296

[1713497296]

1713497296

[1713497296]

1713497296

[dwdollar]

Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?

64bit Client Error, will try out 32bit client and see if the error is similar.

Code:

./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

The machine I tested this on uses nothing but the stock builds, no modified builds were used prior.

Same error for 32bit client

Code:

./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)

I'm getting this too on 32-bit Ubuntu 9.10.

It works fine on 32-bit and 64-bit Ubuntu 10.04.

[jgarzik]

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.

I will echo a recommendation to satoshi from another forum member:  build linux binaries on an older Linux OS, to ensure wider compatibility.  Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).

[knightmb]

Ah, mine is linked to 2.10.1, I'll bring my system up to bleeding edge to see if that solves it  

[edit] Well turns out I can't package wise as they top out at 2.10 for now

[knightmb]

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.

I will echo a recommendation to satoshi from another forum member:  build linux binaries on an older Linux OS, to ensure wider compatibility.  Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).

I would agree, would help those of us not on the bleeding edge of distro packages. 

[bitcoinex]

0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)

If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.

I will echo a recommendation to satoshi from another forum member:  build linux binaries on an older Linux OS, to ensure wider compatibility.  Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).

sorry. I'm checked binaries on Debian GNU/Linux squeeze/sid

[satoshi]

"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it?  This was built on the same OS installations as 0.3.0.

Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0.  I will not upgrade anymore.  I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.

[The Madhatter]

v0.3.6 works on FreeBSD/i386 7.2,7.3 and on FreeBSD/amd64 8.0

Compiles cleanly without any warnings, and appears to be working fine.

[Odin]

Maybe the points listed in http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.

Getting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.

[SmokeTooMuch]

0.3.6 works great on Win7 Pro 64-Bit.

[Gooffy]

Ubuntu Linux 9.10

Error:

/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found       

[bitcoinex]

Ubuntu Linux 9.10

Error:

/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found       

$ dpkg -l|grep -i glibc
ii  libdb1-compat                            2.1.3-9                         The Berkeley database routines [glibc 2.0/2.


?

[lachesis]

On Debian testing 32-bit, I get a few build errors, all resembling:

Code:

script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope

I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.

If anyone else gets this error, the simplest solution is to "make clean" and retry the build.

[dwdollar]

"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it?  This was built on the same OS installations as 0.3.0.

Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0.  I will not upgrade anymore.  I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.

That's strange, 0.3.3 worked fine on it.  It's no biggie, I need to upgrade that machine anyway.

[Odin]

Ubuntu Linux 9.10

Error:

/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found      

dpkg -l | egrep "(libc6|glibc)"
# This will display what version you currently have installed

# I guess you have glibc version 2.10 or older installed.

apt-get update
apt-cache showpkg libc6 | less
# Look (near the bottom) for the versions available for a 2.11 version

#Maybe you can just upgrade with:
apt-get upgrade libc6


# Above instruction for a real debian system, they might work with Ubuntu

[satoshi]

On Debian testing 32-bit, I get a few build errors, all resembling:

Code:

script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope

I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.

If anyone else gets this error, the simplest solution is to "make clean" and retry the build.

We don't really need pre-compiled header.  It only makes it compile slightly faster.  I think I'll just get rid of it.  Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.

Damn that GLIBC_2.11.  I thought I'd been careful not to accept any of the updates.

[knightmb]

We don't really need pre-compiled header.  It only makes it compile slightly faster.  I think I'll just get rid of it.  Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.

Damn that GLIBC_2.11.  I thought I'd been careful not to accept any of the updates.

I was going to compile a GLIBC_2.10 version until I noticed that I had to keep installing more and more to get through the check errors, LOL. Looks like I just need to fire up a Virtual Box with all the dev packages loaded to do this in a virtual machine to make life easier.

[bytemaster]

Could someone help me understand why it matters that hashing is 2x faster?  If everyone were to upgrade the coin inflation rate would still remain the same.  Thus there is a "slight" advantage to early adopters.  I guess some could say it gives "honest nodes" more time and thus makes it even harder for dishonest nodes to gain an edge.

The #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy.  So I would think we would want to focus on aspects other than "generation speed" first.

[knightmb]

Could someone help me understand why it matters that hashing is 2x faster?  If everyone were to upgrade the coin inflation rate would still remain the same.  Thus there is a "slight" advantage to early adopters.  I guess some could say it gives "honest nodes" more time and thus makes it even harder for dishonest nodes to gain an edge.

The #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy.  So I would think we would want to focus on aspects other than "generation speed" first.

Quite simply to level the playing field for coin generation and to help maintain block generation at a stable rate. If everyone was limited to just 100 khash/s by the client, someone would just compile a client that does not have the limit and load it up on a server farm where they could generate 10,000 khash/s per machine. It would put the coin generation supply in the hands of who ever had a large amount of money to invest in servers and discourage everyone else from trying to mint coin. If we could trust that clients would only act as transaction nodes and that everyone would get a fair shot at coin generation then no one would care if the client was generating at 5 khash/s all the time.

So in a perfect world, no one would care that they can generate 2 or 3 times faster than someone else, but we don't live in a perfect world. 

[Anonymous]

My khash rate went from 700 to 1700.Sweet!