AIR Wiki: Rembrandt Software Compilation

Rembrandt Software Compilation

During building and installing software from sources in /usr/local at the Rembrandt cluster some problems had been encountered and special non-standard commands had to be run. For the various packages yhey will be described in the following sections below.

Iperf V. 1.6.5

The configure part of the make command (at Iperf 1.X versions ./configure will be run from make) fails because the architecture is not recognised. This can be solved by adding at the bottom of the expression in line 159 from cfg/config.sub:

tahoe | i860 | m32r | ...
...
... sparc64 | v850)

the following:

... sparc64 | v850 | x86_64-unknown)

Tcptrace V. 6.6.7

Web100∞ Userland dependency issues

The tcptrace package is depending from the Web100∞ Userland utilitities, a.o. the shared object library. As this is alpha software that can only be used in a Web100∞ environment and using command names that are not very specific we prefer to install the Userland utilitities in a separate directory tree /usr/local/Web100_Userland. This makes it also possible to add only its bin directory to the executable path when a Web100∞ kernel has been used.

The disadvantage is that special commands should be given such that the Userland include files and libraries are found during the building and that also the shared object library could be loaded by the executable. To be able to do this before "/configure ... and make could be run the following environment variables should be set as follows (bash shell syntax):

export CFLAGS="-g -O2 -I/usr/local/Web100_Userland/include/web100"

export LDFLAGS="-g -O2 -L/usr/local/Web100_Userland/lib"
export LDFLAGS="$LDFLAGS -Wl,-rpath,/usr/local/Web100_Userland/lib"

Please note that the loader option -Wl,-rpath,... implies that the Web100∞ Userland lib directory will be add to the shared objects search path of the execuatble. This implies that the Userland shared object is found without needing to set the LD_LIBRARY_PATH environment variable which is pleasant because in this way the system is not drowned by a huge library path in LD_LIBRARY_PATH or wrapper scripts needed to set LD_LIBRARY_PATH only for their specific application.

Another issue is that the installation procedure will write into the current directory, so the building directory should be copied to a local directory and the Java bin path should be in the executable path for root.

Compilation problem

During compilation of tcptrace V. 6.6.7 the following error occurred:

gcc -O2 -DGUNZIP="\"gunzip\"" -DBUNZIP2="\"bunzip2\"" -DLOAD_MODULE_HTTP -DHTTP_SAFE -DHTTP_DUMP_TIMES -DLOAD_MODULE_TRAFFIC -DLOAD_MODULE_SLICE -DLOAD_MODULE_RTTGRAPH -DLOAD_MODULE_COLLIE -DLOAD_MODULE_REALTIME -DGROK_SNOOP -DGROK_TCPDUMP -DGROK_NETM -DGROK_ETHERPEEK -DGROK_NS -DGROK_NETSCOUT -DGROK_ERF -DYYTEXT_POINTER=1 -DHAVE_LIBM=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_UNSIGNED_LONG_LONG_INT=8 -DSIZEOF_UNSIGNED_LONG_INT=8 -DSIZEOF_UNSIGNED_INT=4 -DSIZEOF_UNSIGNED_SHORT=2 -DHAVE_MKSTEMP=1 -DHAVE_VALLOC=1 -DHAVE_MEMALIGN=1 -DHAVE_INET_PTON=1 -DUSE_LLU=1 -D_BSD_SOURCE -I. -I/usr/local/include -I. -I../pcap -I/usr/include/pcap -c -o filt_scanner.o filt_scanner.c
./filt_scanner.l: In function `filtyywrap':
./filt_scanner.l:159: error: `yytext_ptr' undeclared (first use in this function)
./filt_scanner.l:159: error: (Each undeclared identifier is reported only once
./filt_scanner.l:159: error: for each function it appears in.)
make: *** [filt_scanner.o] Error 1

The reason appeared to be that in filt_scanner.c at line 166

#define unput(c) yyunput( c, (yytext_ptr) )

end in line 336-337:

extern char *filtyytext;
#define yytext_ptr filtyytext

That combination did not seem to be understand by the GCC V. 3.3.5 (Debian 1:3.3.5-2) preprocessor. Permutations of the order did not help.

The solution was to uncomment in filt_scanner.l at line 155-161:

int yywrap(void)
{
if (0)
unput(0); /* never really called, but shuts up gcc */

return(1);
}

the if (0) unput (0); lines (157-158). As it is never really called it could also be skipped.

Vim V. 6.3

The Vim editor has been build using the Motif toolkit such that XRDB support is maintained and with "multi-byte" support for compatibility with the RedHat VanGogh nodes. This could be done by editing src/Makefile, after unpacking of the distribution, as follows:

Enable Motif by uncommenting the line:
CONF_OPT_GUI = --enable-gui=motif

Let "autoconfig" check for the multi-byte feature by uncommenting the line:
CONF_OPT_MULTIBYTE = --enable-multibyte

Also patches to the source distribution were applied. For the ease of use the own written small script patch_vim will be used for that porpose. The current version is hard coded into it in the shell variable VIM_VERSION. The Vim building and installing procedure has a difficulty with NFS mounted file system (file time issues?). Therefore the building and installing is performed at each host in /tmp. The following command lines will be used for that.

cd /tmp
tar xfvj ~/Install/vim-6.3.tar.bz2
tar xfvz ~/Install/vim-6.3-extra.tar.gz
tar xfvz ~/Install/vim-6.3-lang.tar.gz
cd vim63
~/Install/vim-6.3_patches/patch_vim
cd src
vi Makefile # Enable Motif and multi-byte
make

su -

cd /tmp/vim63/src
make install

UDT V. 1.3

The UDT library should be compiled with the option -m64. Otherwise the obtained throughput (a.o. to the loopback device) will be very low, about 20 Mbits/s. It looks like if congestion did occur. The -m64 option could be set in the form CCFLAGS += -DIA64, below the fragment

ifeq ($(arch), IA64)
CCFLAGS += ...
endif

in the make files src/Makefile and app/Makefile.