I'm going to take the easier route, found a virtual box of Ubuntu 9.04, so I'm going to fire one up, go through the instructions again and see if I can compile a version that isn't using the latest glibc library for those of us on old distros 

That seems to solved the problem, but now it hangs on the wxWidgets 2.9 with a screen full of "undefined reference" errors in the for the displayx11.cpp files. 

I think I might have an easier time compiling on the same Distro that he uses in a virtual box rather than have hunting down all these errors.

I know I've seen this topic a half-dozen times (can't compile), but after spending hours hunting down source and compiling every piece of software listed in the build-unix.txt, correcting path errors in the build files, etc.  I still can't get the program compiled on my Mandriva 2010.0 box, LOL.

The error it hangs at is:

The program is there, but I'm not familiar enough with how the boost software works to fix the error. If anyone has any feedback or ideas it would be greatly appreciated. I would like to catch up with everyone else on the Linux client front, but I won't be able to use the new version until the next release that supports Linux builds not using bleeding edge software  

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. 

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.

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

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

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

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.

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

Same error for 32bit client


Linux - Mandriva 2010.0 [64bit and 32bit] OS systems setup

Tested the Windows build across XP, 2003, Vista, 7 (both 32 and 64bit builds), no issues installing or running client. So far so good, looking forward to the Linux client. 

I think changes have been committed now.

Both can work, but a members forum would help to keep out the noise; otherwise everyone will end up messaging the lead developer with every possible thing they here in the news and end up taking his/her time to filter it out on whether it's really a risk or not.

Since we mostly communicate by forum here, the closest would be a member group that has access to a special forum here just for that issue that the public can't normally see. I'm fairly certain the simple machines forum supports that feature?

In this forum, I don't see why not. Basically, the implementation bug means that the client wasn't following it's own rules. Someone may have found a way to double-spend coin for example that the Client doesn't catch because of how it processes the rules to counter this kind of action.

Yes, I've tested on Windows XP, 2003, and 7 all went through just fine. You'll enjoy the speed increase as well.  

[err, wait I guess, new version about to spawn]

I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release 

So far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity. 

I appreciate the quickness of this security update, but unfortunately none of the Linux builds work (32bit or 64 bit) because the file is missing. I'm assuming if I go find the file it will work, not sure what luck others will have though using the new build.

Error

Well it's good for me, I can change images around as needed. Your optimizations have actually made a bunch of old Celeron machines I had able to do almost 500 khash/s now when they could barely squeak by 100 khash/s before. I need to send some more BTC to you so that it covers the *acceleration* tax now   [payment sent]

Well this certainly blows away my Linux machines now. I hope these kind of optimizations make it into the Linux builds on day.