# 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

## GENERAL

<h0>Q1.1: What do I need to install Tela?</h0>

> `

> > ##

> > > > > > > > > > ##

> > > > > > > > > > ##

> > > > > > > > > > ##

> > > > > > > > > > ##

>     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.

>      <h0>Q1.2: Where to obtain more information?</h0>
>     Read the file INSTALL in the main source directory.

>     COMPILATION

>      <h0>Q2.1: The compilation stops in files.ct in HDF include files with many errors.</h0>
>     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.

>      <h0>Q2.2: I have problems with the Makefile on IRIS system?</h0>
>     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).

>      <h0>Q2.3: It doesn't find some include files.</h0>
>     Check variables containing INCLUDE in makeinc and Makefile.
>     Do grep INCLUDE makeinc Makefile.

>      <h0>Q2.4: It complains about multiply defined outputters e.g. in codegen.C.</h0>
>     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.

>      <h0>Q2.5: The compiler gets stuck in objarithm.C.</h0>
>     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.

>      <h0>Q2.6: The compiler runs out of memory.</h0>
>     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.

>      <h0>Q2.7: The compiler crashes in fftpack.C.</h0>
>     This may happen under AIX if you use -O3. Use -O2 for that file.

>      <h0>Q2.8: flex++ complains about bad options!</h0>
>     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

>      <h0>Q3.1: All LAPACK functions seem to be undefined in linking phase.</h0>
>     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.

>      <h0>Q3.2: tputs or something similar seems to be undefined.</h0>
>     You probably forgot to insert -ltermcap to READLINELIB.

>      <h0>Q3.3: alloca is undefined.</h0>
>     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.

>      <h0>Q3.4: Some Fortran-specific stuff seems to be undefined.</h0>
>     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

>      <h0>Q4.1: install.sh seems to install only part of the files.</h0>
>     Yes. I know. install.sh actually does not work properly.
>     I should write a better one. Meanwhile, get and install (!) GNU install.

>     RUNTIME ERRORS

>      <h0>Q5.1: The linear algebra functions seem to produce garbage results.</h0>
>     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.

>      <h0>Q5.2: The FFT routines produce garbage.</h0>
>     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++.

>      <h0>Q5.3: Sometimes I see weird hex numbers where I expect to see a string in output?</h0>
>     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

>      <h0>Q6.1: Problems on Cray UNICOS 8.0.3 using scc4.0 and C++1.0?</h0>

>     - 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 <stdio.h>
>     #include <string.h>

>     #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

>     Back to Tela home page

> `