in the last weeks, i had to compile several libraries for our ultrasparc machine running solaris (sunos 5.10). in particular, these libraries were gmp, atlas, iml, ntl and boost. i wanted to use the sun studio c/c++ compiler (cc has version 5.8, CC has version 5.9) instead of gcc/g++. moreover, i need 64 bit versions of everything, since my programs need a lot of memory. (the machine has around 140 gb of ram anyway, so it makes a lot of sense.)

since it was somewhat troublesome to get everything running (atleast running enough so that i could use what i needed), i want to describe the process of compiling everything here. maybe this is useful for someone…

i compile everything into my home directory, /home/felix. i also use stlport4 instead of the sun studio standard c++ stl, since i couldn’t figure out how to compile boost with the usual stl. the code generated will not be portable, but should be fast.

gmp.

for configuration and compilation, i did the following:

$ export CC=cc
$ export CXX=CC
$ export CFLAGS=’-m64 -fast -xO3 -xarch=native64 -xchip=native -xcache=native’
$ export CXXFLAGS=’-m64 -fast -xO3 -xarch=native64 -xchip=native -xcache=native -library=stlport4′
$ ./configure –prefix=/home/felix
$ gmake
$ gmake check
$ gmake install
$ gmake distclean

i didn’t add the –enable-cxx switch for configure, since this didn’t work and i didn’t need it. note that i chose the optimization level -xO3 instead of -xO4 or -xO5 since otherwise some of the checks failed. you can try a higher level, but i urge you to run gmake check and reduce the level when checks fail.

atlas.

to build atlas, i proceeded as follows. you can replace mybuilddir with any other sensible name; that directory will contain all build specific files for that machine. note that atlas does some profiling to determine which methods are fastest, so it is better to not have anything else running on the machine while building atlas. i didn’t build the fortran parts of the library (by –nof77), as well as the fortran tests, since i couldn’t get them to link correctly. (one probably has to set FFLAGS or however the corresponding variable is called…)

$ mkdir mybuilddir
$ cd mybuilddir
$ export CC=cc
$ export CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ ../configure –nof77 –prefix=/home/felix –cc=cc –cflags=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ gmake
$ gmake check
$ gmake ptcheck
$ gmake time
$ gmake install
$ cd ..

iml.

building iml is rather easy. it needs both gmp and atlas.

$ export CC=cc
$ export CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ ./configure –prefix=/home/felix –with-gmp-include=/home/felix/include –with-atlas-include=/home/felix/include –with-gmp-lib=/home/felix/lib –with-atlas-lib=/home/felix/lib
$ gmake
$ gmake check
$ gmake install

ntl.

buliding ntl is a bit more complicated. it requires that gmp is already built. the whole process is more complicated since on our machine, a little tool called MakeDesc called at the beginning of the build process hangs. the problem lies in src/MakeDesc.c, when the main program calls DoublePrecision1(one) in order to find out the (internal) precision of double registers. if i replace the line

dp1 = DoublePrecision1(one);

by

dp1 = dp;

the whole process works perfectly – though maybe some things will not be 100% correct in the end. (but i’m willing to take that risk.)

$ cd src
$ export CC=cc
$ export CXX=CC
$ export CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’
$ export CXXFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native -library=stlport4′
$ export LDFLAGS=’-R/home/felix/lib -library=stlport4′
$ ./configure PREFIX=/home/felix CC=cc CXX=CC CFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native’ CXXFLAGS=’-m64 -fast -xarch=native64 -xchip=native -xcache=native -library=stlport4′ LDFLAGS=’-R:/home/felix/lib’ NTL_GMP_LIP=on GMP_PREFIX=/home/felix
$ gmake
$ gmake check
$ gmake install
$ cd ..

boost.

finally, i had to compile boost. after a lot of trying and fiddling, i found out that these calls seem to work:

$ ./bootstrap.sh –prefix=/home/felix –show-libraries –with-toolset=sun –with-libraries=iostreams
$ ./bjam –prefix=/home/felix toolset=sun –with-iostreams threading=multi address-model=64 link=static install

note that i only build the iostreams library of boost. remove the –with-libraries=iostreams to (try to) build all libraries.

conclusion.

yes, the whole process is pretty much a pain in the ass. just installing the packages with apt-get on some debian-based linux, or compiling them from scratch on a gcc/g++ based linux, is just sooo much easier. but then, if you have a solaris machine standing around, why not use it to crunch some numbers for you? :-) (especially since currently, i essentially have the machine for myself.)
to compile my code, i use

$ CC -I/home/felix/include -m64 -fast -xarch=native64 -xchip=native -xcache=native -c -library=stlport4 object files and so on;

to link, i do

$ CC -m64 -fast -xarch=native64 -xchip=native -xcache=native -L/home/felix/lib -R/home/felix/lib -library=stlport4 -lntl -liml -lcblas -latlas -lgmp -lm -lboost_iostreams -lz object files and so on.

while talking with a friend about learning programming, i searched for course material for the best programming course i ever had so far, namely dibo‘s “programmierkurs java” (which i praised so often when it comes to this topic). while looking, i found a new website by dibo, called programmierkurs java, which features the lectures (both slides and video recordings!) and exercises. in case you want to learn programming and understand german well enough, take a look there!
ok, so much for advertising. when taking to the friend, another topic was “what is the right programming language to begin with?” in this case, the canidates java and c++ were named. i would definitely go for java, even though i prefer to use c++ myself for most things i program, as java is more allergic to programming errors: if you try to access an array out of the boundaries, it will throw an exception and will not result in unexpected behaviour. moreover, it is widely available (for free!) and easy to set up, there is a huge amount of (good and bad) literature about it, it is not too far off from the real world programming languages which one might use later (in case one wants to learn more than one language, it might also be a good idea to start with something more esoteric, like functional programming). moreover, it can be used both imperatively (which is in particular useful in the beginning) and object oriented (which one shouldn’t touch too early, in my opinion).