TR Forums

If you are getting errors starting the fah6 client in Ubuntu 10.04, this workaround worked for me.

Man, these little problems are annoying if I just want to load the ISO, install *buntu on a VM, grab FAH and then just go. 9.10 RTM had the annoying Samba problem (speaking of which did they patch this one? on a Folding-only VM I don't feel like updating) which prevents from effective monitoring. So do I have to go all the way back to 9.04?

Is this latest problem Stanford's (not recompling with the more restricted library?)? Or *buntu's? I kind of want to use 10.04 because of the LTS label, but...

Flying Fox wrote:

Is this latest problem Stanford's (not recompling with the more restricted library?)? Or *buntu's? I kind of want to use 10.04 because of the LTS label, but...

As best I can tell this one is actually Stanford's problem. Looks like they were relying on an undocumented/unsupported runtime library function, which went away in 10.04.

This worked for me on my VMwared client on my aged socket 939 Opteron. Thanks for the info. This may be sticky-worthy, for a while at least.

While I'm at it, the thread where I announced a Linux SMP core update almost 2 years ago should probably have been unstickied at least a year ago.

Ragnar Dan wrote:

While I'm at it, the thread where I announced a Linux SMP core update almost 2 years ago should probably have been unstickied at least a year ago.

Fixed.

Ragnar Dan wrote:

This worked for me on my VMwared client on my aged socket 939 Opteron. Thanks for the info.

You're welcome! Funny you should mention Socket 939 Opterons; I hit this issue myself while trying to resurrect an old Socket 939 motherboard and dual-core Athlon someone had given me. Figured I might as well also use it as an Ubuntu 10.04 testbed.

This may be sticky-worthy, for a while at least.

While I'm at it, the thread where I announced a Linux SMP core update almost 2 years ago should probably have been unstickied at least a year ago.

Yeah, I'll go and rearrange the stickies...

Edit: Oops, Cap'n beat me to it.

Edit #2: He only un-stickied the old thread. I've sticked this one. Someone remind me to un-sticky it when Stanford releases a fix...

just brew it! wrote:

Ragnar Dan wrote:

This worked for me on my VMwared client on my aged socket 939 Opteron. Thanks for the info.

You're welcome! Funny you should mention Socket 939 Opterons; I hit this issue myself while trying to resurrect an old Socket 939 motherboard and dual-core Athlon someone had given me. Figured I might as well also use it as an Ubuntu 10.04 testbed.

I keep assuming new releases, especially long term stable ones, will be only slightly different from prior releases. I know it's supposed to be Stanford's fault that they used an unsupported function call, but that sort of thing is the bane of long-term software projects. Of course, it's probably not the Ubuntu people's doing either, but whatever. There's something to be said for a single source, especially when they're good at publishing their changes, give away free compilers and lots of info about them and the API, and fairly admirable in the way they try to keep older software working with new OSes. (Now I've P.O.'ed the Linux-geek crowd.)

Yeah, Linux's diversity and rapid evolution is simultaneously a strength and a weakness.

I've occasionally attempted to rebuild packages from current upstream source, when there was a particular new feature I wanted, or a bug which the upstream fixed (or that I thought I could fix myself). It has ranged from dead simple (Bluefish text editor) to moderately annoying (Audacity audio editor) to an absolute train wreck of library version dependencies (Audacious music player). It is issues like this which make me skeptical that Linux will catch on any time soon as a gaming platform; if I was a game publisher, I'd certainly think twice about having to support even just the last couple of versions of the most popular distros.

Just a quick update on this...

The same workaround appears to work for Ubuntu 10.10, but make sure you repeat all of the steps. I had gotten into the habit of just copying the lib64-fah folder (containing the hacked runtime libraries) from a previous system each time I set up a new one, instead of redoing the entire procedure from scratch. This works fine as long as you're copying the libraries to another system running the same version of Linux; but if you copy libraries which were prepared on (say) 10.04 to a system running (say) 10.10, the F@h client will crash repeatedly.

In retrospect I should've known better; runtime libraries are tied to the kernel they are built for.