Building BOINC applications

When building a BOINC application, you typically

• want versions for several platforms (Windows, Mac OS X, Linux);
• want each version to run on a wide range of volunteered computers (e.g. the Linux/x86 version should run on Linux systems of many ages and types).

Achieving these goals can be challenging. However, BOINC provides tools and example files that simplify the task.

Whether you're creating a new application or adapting an existing application to BOINC, we recommend that you start by building the BOINC sample application example_app on all the platforms you want to support. When this is done, you can use the example application and its associated project files as a basis for your own application.

The first step in building the example application on a given host is to checkout the boinc module? on that host. Put them in the same parent directory.

Windows

We use Windows XP for builds (other Windows versions may work too).

Microsoft Visual Studio

Go to boinc/win_build. If you're using Visual Studio 2005, open samples.sln. If you're using Visual Studio 2003, open samples_2003.sln. Select 'Build/Build? Solution', or hit F7. That's it!

There is a free version, ​Visual C++ 2008 Express Edition, which works with the BOINC project file (after it is converted). You'll also need the ​Microsoft Platform SDK and some ​changes to your Visual Studio Express installation to include the SDK. Warning: you cannot use more recent versions of the SDK (which do not include glaux).

If you use your own project file:

• If your application uses graphics, go to Properties -> Linker -> Input. In Delay Loaded DLLs add

  GDI32.DLL;OPENGL32.DLL;GLU32.DLL
  

  and in Additional Dependencies add

  delayimp.lib
  

• Configure your project to use ANSI strings rather than Unicode.

MinGW and Dev-C++

If you can't or don't want to use Visual Studio to build applications, the easiest alternative is ​Dev-C++, an open-source development environment based on the GCC compilers. Use the MinGW compile option.

The boinc/lib and boinc/api directories contains makefiles (Makefile.mingw) for building the respective libraries.

SETI@home uses Dev-C++ for its Windows build; you can get the project file ​here.

MinGW command-line (Cygwin, cross-compile)

To build the boinc library and API for Windows using MinGW, use lib/Makefile.mingw.

Per default the targets libboinc_api.a libboinc.a and libboinc_graphics2.a are built. Optional targets are libboinc_zip.a (requires the boinc_zip tree), and the usual clean, install and uninstall targets.

The following environment variables influence the build:

• CC and CXX : set to MinGW C and C++ compiler
• AR and RANLIB : set to ar and ranlib of the target system when cross-compiling
• BOINC_SRC : set to the root of the boinc source tree, defaults to ..
• BOINC_PREFIX : set to destination if you want to use install & uninstall targets; defaults to /usr/local/boinc
• NOCYGWIN : set to '-mno-cygwin' if you are building on Cygwin but for use on plain Windows (i.e. w/o cygwin.dll)

Cygwin

​Cygwin may be another alternative for building Windows apps. There are several issues:

• If you build the API library directly, it will use use shared memory to communicate with the BOINC client. This won't work if you use the standard Windows client, which uses memory-mapped files rather than shared memory.
• In order to run a cygwin application from BOINC, you need to supply all the cygwin DLLs that the application requires in addition to the executable. You can get LISTDLLS from ​http://www.sysinternals.com/. It will tell you what DLLs a running executable has loaded.
• Cygwin is GPL software. If you link to the cygwin DLL, then either your application has to be GPL as well, or you will have to buy a commercial license from Red Hat.

However, it can be done. Check the ​cookbook from CERN (search for "Instructions to Port the application to Windows").

Symbol Stores

To obtain useful stack traces in the event of an application crash, symbols are needed. Normally symbols are "stripped" from executables. Without symbols, callstacks are just a list of memory addresses. You then must load the un-stripped executable in memory using the same operating system and similar processor to jump to that memory address in order to determine the function name and parameters. This is very labor intensive.

Microsoft created a technology called a 'Symbol Store' which allows Windows debuggers to locate and download compressed symbol files to diagnose problems and convert function pointers into human readable text. This greatly speeds up the process of diagnosing and fixing bugs.

With the BOINC Runtime Debugger for Windows framework a project can publish their symbol files and only have to distribute the application to each of the BOINC clients. When a crash event occurs the runtime framework will download the symbol file from the symbol store and then proceed to dump as much diagnostic information as possible to help projects diagnose the failure.

Requirements

You'll need the latest stable release of the ​Debugging Tools for Windows.

Verify that your executable is setup to generate PDB debugging symbols for a release build.

Verify that the advance linker option to generate a checksum is enabled for a release build.

You'll need to explicitly name both your EXE and PDB before compilation since the debugger bases the name of the PDB file off of information that is stored in the executable header.

Project Symbol Store

Add a symstore element to your config.xml file for the project:

<boinc>
    <config>
        <symstore>http://sample.example.com/symstore</symstore>
    </config>
</boinc>

Adding symbols to the symbol store

​Symstore is a utility to manage symbol stores. You'll want to create a local symbol store on your Windows build machine in which you'll initially add new symbol files with each revision of your application.

Symstore will compress the symbol file and then copy it into your local symbol store.

Below is an example command which you can run from the Windows command line or cygwin command line.

symstore.exe add /l /f c:\SampleSrc\*.pdb /s c:\symstore /compress /t "Sample" /v "5.02" /o /c "Application Release"

Uploading symbols to the symbol store

Most projects tend to use scp to copy files between Windows machines and their project server.

The example below copies the entire symstore to the target location. After the copy operation you can delete all the subdirectories except '000Admin' to save time uploading for future application symbols.

pscp.exe -r -C -batch c:\symstore sample@project.example.com:projects/sample/html/user/symstore

Mac OS X

Instructions for building applications on Mac OS X are on a separate page.

Linux/x86

If you build an application on a recent Linux distribution, it won't run on older Linux distributions because of library incompatibilities. The only solution we've discovered is to build applications on a host with an old Linux and an old GCC. Setting up such a host, however, is a giant pain.

Our recommended approach is not to build directly on a Linux host, but rather:

• If you are using Windows XP with SP2 or below install ​Microsoft Virtual PC 2004 SP1. If you are using Windows XP with SP3 or Windows Vista install ​Microsoft Virtual PC 2007 SP1. We recommend to use a Windows XP machine (preferably one that's fast and has lots of disk).
• Download the Compatibility virtual machine module. This is a Debian Linux system with the appropriate (old) version of GCC.
• Run this system under Virtual PC.
• Install the stable server code? on the virtual host.
• Build the BOINC libraries by going to the 'boinc' directory and typing:

  _autosetup
  ./configure --disable-client --disable-server LDFLAGS=-static-libgcc
  make
  

  For x86-64 builds, it's possible to take SSE2 for granted, as long as GCC is version 4.0+, then type instead:

  _autosetup
  ./configure --disable-client --disable-server LDFLAGS=-static-libgcc CFLAGS=-ftree-vectorize CXXFLAGS=-ftree-vectorize FFLAGS=-ftree-vectorize
  make
  

Do not 'make install'.

• Go to the boinc/samples/example_app directory and type:

  ln -s `g++ -print-file-name=libstdc++.a`
  make
  

Other UNIX systems

• Software prerequisites
• configure/build

GLUT notes

Freeglut 2.2, freeglut 2.4 and OpenGL Utility Toolkit (GLUT) libraries are supported.

X11 notes

To get the X11 support, select the relevant options when you're installing Linux, or (Redhat) go to System Settings/Add? Software.