Tag Archives: boinc

BOINC localhost auto-authentification

If automatic authentification on BOINC GUI (i.e. Manager) startup doesn’t work, check that gui_rpc_auth.cfg in BOINC’s home directory is readable by the user who’s ID starts the GUI. That’s /var/db/boinc/gui_rpc_auth.cfg on my system, for example.

Advertisements

Building my simple BOINC application under Windows

It was developed and tested under FreeBSD. Then I had to compile and build it under Windows.

First I tried Cygwin and failed due to some defenitions missing in Cygwin’s libraries. Or my installed libraries. Heck, it was so many error lines ago, I can’t even remember what it was.

Then I tried Dev-C++. I used the same Cygwin tools, but this time I let Dev-C++ generate a Makefile.win and build from that. First, it found some error in the Makefile (“% missing”). I think I just deleted that line, it was nothing important. Anyway, Cygwin went as far as to the linker stage, at which he couldn’t find the BOINC-specific symols in the supplied libraries.

Of course, the libraries weren’t compiled at that point. So I proceeded to, but that produced some errors, too. After a few hours I gave up.

… Well, not exactly. I went on to “See What the Manual Says!”. It said to build it using MS VC++, Express Edition (which is free).

I downloaded that from my local DC++ network, which was faster.

Also, I installed TortoiseSVN and checked out the BOINC trunks. It was really slow, a tortoise it was, so I copied over the FreeBSD one that was already on the hard drive. Now, adding those files to the local repository was a pain in the ass. Although it turned out I only has to right-click -> TortoiseSVN -> Check for Modifications.

Trying to build the app without the SDK installed yielded no results. No positive results, that is. So I proceeded to download the SDK, as yet again was encouraged in the manual.

Then I ran into a whole heap of linker problems. Jumped aroung with them until 2 past midnight, then remembered my productivity falls dramatically around that period. Went to sleep.

This morning, I understood I should have right-clicked the solution (I added my program to the samples.sln of boinc_samples), checked libboinc and libboincapi as the dependencies for my project. That got rid of boinc-specific symbols not being found. (libboinc and libboincapi were compiled and linked by then.)

Then there were other linker problems: msvcrt.lib (MSVCR80.DLL) had a conflict with one of libboinc.lib’s .objs, and it was turning into a bloody mess.

Guess what? I read the manual.

After that, I changed the /MD option specified to the C/C++ compiler to /MT – link the static multithreading library instead of the dynamic (DLL) one.

Now, a few last words. This would have all lasted for 4 hours instead of 14 if I just sat down and followed the instructions. These hours would be mostly waiting for things to download or compile, and that means I could’ve been doing something else. Which brings us to one conclusion, boys’n’girls:

My very own BOINC server

Yes, that’s true. It’s working. Half-assedly, but it does.

It’s not of much interest from outside of my circle, since it does no useful work. It’s a course project of mine, which is due next Tuesday. The paper isn’t started yet, alhough I did take 25 KB of plaintext UTF-8 notes.

Anyway, there’s a lot of stuff among those notes, surely could be a heap of valuable tips.

MalariaControl and Rosetta@Home

The first one is working OK, except for there is no graphics. But the WU are being submitted, validated and accepted.

Now, Rosetta@Home seems to have a bug o some sort, which makes the client detach every time Rosetta gets a work unit. Maybe you need to suspend all other work units first. I’ll try it.

wx-config missing in FreeBSD

It is required by many applications dependent on wxWidgets to determine which version exactly (wxgtk24, wxgtk26, wxgtk28…) is being used. It also allows specifiying diretly which version to use.

To be precise, wx-config is a wrapper/redirect to the real wx*-config script. So check if you have that:

%ll /usr/local/bin/wx*
-r-xr-xr-x 1 root wheel 42259 Apr 27 13:06 /usr/local/bin/wxgtk2-2.8-config
-r-xr-xr-x 1 root wheel 42246 Apr 6 02:35 /usr/local/bin/wxgtk2u-2.8-config
-r-xr-xr-x 1 root wheel 66188 Apr 27 13:06 /usr/local/bin/wxrc-gtk2-2.8
-r-xr-xr-x 1 root wheel 77156 Apr 6 02:35 /usr/local/bin/wxrc-gtk2u-2.8

As you can see, wxgtk2-2.8-config is present. (If not, add wxgtk28 port. I built it from source.)

You can now do:

%sudo ln -s /usr/local/bin/wxgtk2-2.8-config /usr/local/bin/wx-config

You need to link this and not just copy the wx-config from wxgtk28’s work directory, since the latter file also references $wxgtk28_work_dir/lib/wx/config/gtk2-ansi-release-2.8 and not /usr/local/bin/wxgtk2u-2.8-config.

I can now build boinc-client, which was reporting wxWidgets as missing.

MilkyWay@Home and POEM@Home

Both exit with:

<core_client_version>5.10.32</core_client_version>
<![CDATA[
<message>
process exited with code 8 (0x8, -248)
</message>
<stderr_txt>
execv: Exec format error
</stderr_txt>
]]>

Which is quite a common error, by the way, for emulation-run Linux projects.

libGLU.a missing on FreeBSD

It’s a GL Utility static library that’s not provided neither by the freeglut, nor the libglut ports. Yet it’s required to build boinc_example and other boinc-related graphics.

One possible solution is using MesaGL. (It’s available in packages on Linuxes, by the way.)

Download MesaLib from SourceForge. Extract to your favourite source directory.

From here, compiling linux-static works well, but then hangs during make install (I don’t save the exact line on which it does, sorry. But it was the stage where it checks all the directories in order to copy the files.) You can copy the static libraries form the lib dir manually.

An alternative would be to provide an option to run make freebsd-static.

What I did is:

==================freebsd-static.diff====================
1c1,2
< # Configuration for generic Linux, making static libs
---
> # Configuration for generic FreeBSD, making static libs
> # Written by cy on 2008-04-23.
3c4
<>
---
> include $(TOP)/configs/freebsd
5c6
< config_name =" linux-static">
---
> CONFIG_NAME = freebsd-static
=====================================================

Then:

cd configs
cp linux-static freebsd-static
patch freebsd-static ../freebsd-static.diff
cd ..

Then edit Makefile and add freebsd-static to Rules section.

That’s it.

make freebsd-static
sudo make install

BOINC projects using 100% of CPU on FreeBSD

uFluids doesn’t send to my platform. Quantum Monte Carlo does. And I’ve decided to give Rosetta@Home one more shot.

Reason? Oh, the reason is great news.

As I’ve written before, some projects somehow take up 100% of processor time, even though the settings unambiguously specify 50%. The reason for this, as I have accidentally found out by fooling around with Wine-emulated BOINC, is idprio.

Idle-time priority is being set to 31 in the /usr/local/etc/rc.d/boinc script. To a logical mind, this would mean that BOINC would only run its 50% share in the idlest of time, when no other process wants it. In reality, BOINC projects get 100% of idle time.

I guess this might be related to the fact that BOINC projects are run as separate threads. On the other hand, this might just be an idprio issue.

Right now, QMC@Home is running with priority nice 19, which it set by itself. The “Show graphics” button doesn’t do anything, probably graphics aren’t installed properly in my system.

It will take 150 hours to finish this workunit. I’d rather test result compatibility on a faster project.

BOINC poll

If you’re using BSD, you can go here and ask
that more projects be supported natively on BSDs.

A solution of BOINC and WINE

I got so frustrated at trying to find a project that supports FreeBSD that I switched to WINE emulation. Let’s see how it turns out.

I mean, Leiden Classical doesn’t work, Most Linux projects that do run consume 100% of processor time, and SETI@Home faults with a SIGSEV.

Which is a sad thing, because there’s a whole lot of FreeBSD machines out there running Linux executables half-assedly. Now there’s one more, contributing as “Microsoft Windows XP, X11 Windowing System”.