That gap between Christmas and New Years is a wonderful time if I’m not on project. That’s when I try to tick entries off that “I Wish I Had Time For…” list. Yes, there will probably be a few more posts about the LS-120 saga, but those will come later. For now I discuss the saga of PCLinuxOS and BOINC. Why here in my blog? Because continuing the conversation in private messages isn’t going to help anyone.

I’ve spoken many times about needing a minimal Linux distro for running BOINC. Whenever I’m going to need to break down a machine for use on something I take the time to try one or more disks I ordered from OSDisc.com. Some of the discussion on PCLinuxOS made it seem like it would be a good candidate. I just wish I had visited the forum and searched for BOINC before I bothered trying.

BOINC has been dropped from the repos. There is a bit of brew-ha-ha going on between myself and a few others in the vein of “no it doesn’t – yes it does.” Rather than enjoy that discussion on my own I thought I would let it educate you dear reader.

I’m sorry too, but there are NOT. Everything needed to run the binaries downloaded from Berkeley is already in the repo.

Which is exactly what I did and what I’m talking about.  For the last 13 years, I have used binaries downloaded from Berkeley, ending with the 7.2.42 version from 2014, which I’m still running today.  How could I be doing this if there are missing libraries?  Just this year and just in case it might be needed, I built 7.6.33 from source.   As it turns out, 7.2.42 continues to work fine for me so I’ve only installed 7.6.33 on a couple of machines for test purposes.

No, I’m not going to name the individual. This isn’t about being evil, this is about improper testing being used to form an opinion. We are all guilty of it at some point. I took pictures so you can run the test yourself and come to your own conclusion.

I chose to skip removing unused hardware support. When I checked the list NVIDIA driver was part of it. BOINC would need NVIDIA to make use of the 384 CUDA core in the machine.

Once the install was complete and I had rebooted I installed all updates after refreshing the package lists.

One thing which never ceases to amaze me in the Linux world is installing a brand new ISO only to find north of 300 files need updating.

Once the updates completed I went to the BOINC download page and selected the recommended version, 7.2.42. After it downloaded I rebooted.

You will note that I’m not as good with RPM based distros as I am with Debian based ones. Took me a bit to remember you have to su root.

A search via synaptic for libwx returned nothing. True, I could have dug out the arcane tools which will tell you just what package provides a certain file, but if libwx was mentioned in a package description it should have returned something. I could have performed a Web search which eventually would return this link for a generalized RPM packaging site. If you scroll down and click on the red bar for PCLinuxOS you see the following:

Which shows the package has been renamed so one would need to create a symbolic link from the command line. But, an ordinary user wouldn’t go to such lengths. An ordinary user would try it like I did, probably not even using synaptic to search for the package after getting the error message.

As to my dutiful corresponder, I have a theory as to why it works for you. It’s simple and not far fetched. You started with an older ISO of PCLinuxOS. One which existed well before the rename. You have been applying updates ever since and the updates aren’t good about deleting old stuff. On your 90+ machines which are successfully running BOINC, you have the library which is now missing from the repo. Yes, if it has been renamed for whatever reason, it is missing.

Because I’ve worked in many environments where testing was a religion, not an afterthought, I’ve developed the habit of testing from scorched earth. Even when I check source code into a repository for a client I rename the working directory then perform a clean pull and rebuild to ensure nothing was missed. People would laugh at me for doing that, until they realized the tool we were using wasn’t good when it came to identifying changed modules. Then they all started doing it.

Could I have hodge-podged getting BOINC to work? Probably, but an end user isn’t going to.

Now, I have spent all of the play time I had and won’t be conducting any further tests for many many months. The screen shots are here and everyone can conduct the test themselves. I suspect the rename came about from trying to keep 32 and 64-bit binaries in the same directory. Many distros used to do this, now most don’t.


Leave a Reply