This 5.13 setiathome enhanced client is compiled with a vanilla gcc 4.1 on an
UltraSPARC III Solaris 10 system completely statically and against BOINC 5.4.9
all in 64 bit mode to exploit the capabilities of that CPU kind. Source is from
the 10. May 2006 tarball.

Used libraries are especially:

libcurl/7.15.1 OpenSSL/0.9.8a fftw 3.1.1

which were also compiled by myself, the fftw library with Sun Studio 11
instead gcc 4.1 (fftw was done with CC=cc, CFLAGS=
-xO5 -xtarget=ultra3 -xarch=v9b -fround=nearest -xvis -xvector -xlibmopt and
./configure --enable-single --disable-fortran --libdir=/usr/local/lib/sparcv9 --enable-threads).

Invocation of configure:

./configure --disable-server --enable-bitness=64 --disable-graphics --enable-client-release

Compiler flags for setiathome_enhanced are

CFLAGS="-O4 -ffast-math -funroll-loops -ftree-vectorize -fstack-protector -m64 -mcpu=ultrasparc3 -mvis"
CXXFLAGS="$CFLAGS"
LDFLAGS=/usr/local/lib/sparcv9/libssp.a

and the lib ssp of gcc 4.1 finally statically linked too into it, giving
the client and app some resistence against eventual buffer overflows regarding
possible exploiting such (I propose anyway to set on every SPARC (sparcv9) and
AMD64 system running Solaris  set noexec_user_stack=1  in /etc/system to 
prevent 32 bit binaries executing code on the stack, which is a common
security threat --- 64 bit Solaris software can't execute code on the stack
at all, if you don't be aware of; but the ssp protection makes it even harder
to sidestep this countermeasure --- which is still possible).

The usage of fftw causes creation of wisdom.h scheduling/benchmark files in the
slot sub directories.

Finally I made one minor source modification because of usage of gcc 4.1, which is
more picky about certain C++ constructs:

in line 78 in db/sqlblob.h it has to be

   b.mem=new std::vector<T>(xml_decode_string<T>(buf.c_str()+start,end-start,enc_string));

instead the original; i.e. the <T> after xml_decode_string was missing.   
