Tela Installation Frequencly Asked Questions For 1.22 GENERAL Q1.1: What do I need to install Tela? Q1.2: Where to obtain more information? COMPILATION Q2.1: The compilation stops in files.ct in HDF include files with many errors. Q2.2: I have problems with the Makefile on IRIS system? Q2.3: It doesn't find some include files. Q2.4: It complains about multiply defined outputters e.g. in codegen.C. Q2.5: The compiler gets stuck in objarithm.C. Q2.6: The compiler runs out of memory. Q2.7: The compiler crashes in fftpack.C. Q2.8: flex++ complains about bad options! LINKING Q3.1: All LAPACK functions seem to be undefined in linking phase. Q3.2: tputs or something similar seems to be undefined. Q3.3: alloca is undefined. Q3.4: Some Fortran-specific stuff seems to be undefined. INSTALLATION Q4.1: install.sh seems to install only part of the files. RUNTIME ERRORS Q5.1: The linear algebra functions seem to produce garbage results. Q5.2: The FFT routines produce garbage. Q5.3: Sometimes I see weird hex numbers where I expect to see a string in output? PROBLEMS ON SPECIFIC MACHINES Q6.1: Problems on Cray UNICOS 8.0.3 using scc4.0 and C++1.0? ANSWERS TO QUESTIONS GENERAL Q1.1: What do I need to install Tela? First and foremost you need a working C++ compiler. For example, g++ or Cfront can be used. LAPACK and BLAS libraries, GNU Readline library, HDF library plus include files. PlotMTV1.4.1t or later for graphics. In addition you may find it convenient to have bison++ and flex++ parser generators installed. A Fortran compiler is not strictly necessary if you have precomplied LAPACK/BLAS libraries, but the necessary Fortran runtime libraries must be there. Q1.2: Where to obtain more information? Read the file INSTALL in the main source directory. COMPILATION Q2.1: The compilation stops in files.ct in HDF include files with many errors. The HDF library include files expect one of the HDF-specific machine names to be defined. For a list see ls MAKEFILE* in the HDF source directory. If your machine is not directly supported, you can usually do rather well by using an alternative. For example on HPUX HDF library compiles with -DSUN or -DIRIS. Just be aware that byte ordering is significant, therefore on Linux you should use SUN386. Of course you want to use the same -D macro when compiling libdf.a and Tela. Q2.2: I have problems with the Makefile on IRIS system? Some IRIX versions have a buggy make. At least 5.2 has this problem. Use GNU make to avoid problems (this is a good hint for all other software packages too). Q2.3: It doesn't find some include files. Check variables containing INCLUDE in makeinc and Makefile. Do grep INCLUDE makeinc Makefile. Q2.4: It complains about multiply defined outputters e.g. in codegen.C. There are two possibilities. 1) BROKEN_UCHAR_OUTPUTTER has been defined wrong in makeinc. 2) your C++ compiler is buggy and is unwilling to compile it for you. In the latter case the only fix is to manually insert (char*) type casts in source code in appropriate places. Q2.5: The compiler gets stuck in objarithm.C. On some systems, for example IRIX6.x in 64-bit mode, it takes very long time to compile objarithm.C using the -O3 optimization. Can't help it, the compiler just spends that time optimizating the thing. Just wait. Q2.6: The compiler runs out of memory. This may happen under AIX if you use -O3. Buy more memory, try to reconfigure your virtual memory (hope you can find someone who knows how), or reduce optimization level to -O2. Q2.7: The compiler crashes in fftpack.C. This may happen under AIX if you use -O3. Use -O2 for that file. Q2.8: flex++ complains about bad options! Your flex++ probably is not the flex++ Tela wants. Sometimes the ordinary GNU flex installer does ln -s flex flex++ because flex has some C++ features. Get the real flex++ from ftp.funet.fi:/pub/sci/math/tela/needed/, or define FLEX++ = true in makeinc. LINKING Q3.1: All LAPACK functions seem to be undefined in linking phase. The Fortran compiler encodes the external names for the linker. Among the used practices for Fortran subroutine foo are: foo (no encoding) HPUX, AIX foo_ Most other Unix systems and f2c FOO Cray UNICOS (On AIX this can be changed by the user.) Tela C++ code must conform to the practice used by the Fortran compiler. The file affected is lapack.H. A mismatch in NO_UNDERSCORE_IN_FORTRAN_NAMES shows up in linking phase as an army of undefined symbols. Q3.2: tputs or something similar seems to be undefined. You probably forgot to insert -ltermcap to READLINELIB. Q3.3: alloca is undefined. Your C++ system may not support alloca, or has a buggy support that configure has rejected. This is the case if C_ALLOCA is defined in makeinc. Compile alloca.c by cc -c alloca.c by hand and ensure that alloca.o is among the linked-in files. Q3.4: Some Fortran-specific stuff seems to be undefined. The Fortran runtime support are found in many libraries on different systems. Try -lF77, -lU77, -lI77, -lisam. If you compiled using F-90 compiler the library names are probably different (probably not -lF90 though, that would evidently make life too dull). A useful trick in looking for undefined symbols is to write (in C-shell) cd /usr/lib # or whatever foreach i (lib*.a) echo $i nm $i | grep UNDEFINED_SYMBOL end INSTALLATION Q4.1: install.sh seems to install only part of the files. Yes. I know. install.sh actually does not work properly. I should write a better one. Meanwhile, get and install (!) GNU install. RUNTIME ERRORS Q5.1: The linear algebra functions seem to produce garbage results. Check that the floating point precision of your LAPACK/BLAS routines matches Treal and Tint in Tela (in def.H). By default Treal is defined to be double and Tint is defined to be int. Q5.2: The FFT routines produce garbage. This should no longer occur if you are using Tela version 1.21 or later. On earlier versions this is probably because you failed to compile FFTPACK with -r8 or equivalent switch. FFTPACK is formally single precision (REAL) while Tela expects double precision (C type double), therefore the Fortran compiler must be forced to promote REALs to DOUBLE PRECISION using a command line switch. On Tela>=1.21 this no longer happens because fftpack has been translated in C++. Q5.3: Sometimes I see weird hex numbers where I expect to see a string in output? Some C++ systems handle iostream unsigned char* outputting incorrectly, i.e. they output not a string but the pointer in hex. The configure script tries to recognize this but the check has been somehow fooled in your case. Set BROKEN_UCHAR_OUTPUTTER to 1 in makeinc. PROBLEMS ON SPECIFIC MACHINES Q6.1: Problems on Cray UNICOS 8.0.3 using scc4.0 and C++1.0? - The compiler sometimes crashes on the VECTORIZE macro. By replacing every occurrence of VECTORIZE by the corresponding pragma should help. I used the following small filter program to do the job: #include #include #define MAXLINE 1024 int main() { char s[MAXLINE+1]; char *pos; int i; while (1) { fgets(s,MAXLINE,stdin); if (feof(stdin)) break; pos = strstr(s,"VECTORIZED"); if (pos) { for (i=0; s[i] && (&s[i]) != pos; i++) putchar(s[i]); printf("\n#pragma _CRI ivdep\n"); i+= strlen("VECTORIZED"); for (; s[i]; i++) putchar(s[i]); } else { fputs(s,stdout); } } return 0; } I filtered gatscat.C and object.C through this. - I could not get the readline library working, thus noreadline.c was used instead. - The bison++ parser generator compiles out of box but produces incorrect results! The resulting parser would give syntax error at every ';', for example. - Some of the elementary functions give floating point exceptions on some bad input arguments because the IEEE arithmetic is not in use on Cray. - The -haggress option produces "out of memory during compilation" style messages on objarithm.C. It compiled, nevertheless, but some of the loops are probably not vectorized. - The WHEN_COMPILED string must be made simpler in Makefile