Installation instructions for DEC OSF1 V4.0

Using DEC's cxx compiler

We have also made preliminary tests with DEC's cxx compiler, version 6.0, on a OSF1 V4.0 system. This compiler seems to be rather conformant and discovered a number of places where we involuntarily seem to have used gcc's sloppyness. These are of course fixed now. The largest drawback was that version 6.0 of the compiler did not yet know about the standard C++ headers cmath, cstdlib, etc, which are included instead of math.h, stdlib.h, etc. Otherwise there did not seem unsurmountable obstacles to the use of that compiler.

Unfortunately, we were not able to test the library further on that system, so there may still be a number of places that need minor fixes.

Using gcc as compiler

We have tried to compile deal.II on DEC Alpha workstations under OSF1 V4.0. The main problem seems to be that on this operating system, that the GNU BinUtils are not supported, so we have to use the system assembler. That, however, has a built-in limit for the size of symbol names, which is quickly exceeded in the template-heavy parts of the code. Typical error messages from the assembler therefore spill out several pages of symbols with an interspersed note that that symbol exceeded the maximum line length of the assembler.

Unfortunately, when using gcc2.95 or previous versions or gcc there seems no real way to avoid this. Later versions of gcc will use a different scheme (called squangling, an amalgamation of squeezing and mangling) to mangle C++ names into symbol names that generate shorter symbols. However, this scheme is not readily available on gcc2.95. However, if you are willing to recompile and reinstall gcc, you can switch on the squangling scheme by slighly modifying one of gcc's source files. The full details of this are listed on this page. With this scheme switched on, we were able to compile the library.

Problems do not end here, though. The system assembler, due to its limited line length, also rejects long lines of debugging information. We avoid this by not using the -ggdb switch of gcc, but rather use -gstabs. This generates less debugging information, but the lines are also shorter, so the assembler can digest them. However, you should be aware that this can, in some cases, reduce your ability to debug programs, due to missing information in the debugger.

Finally, the system's ``ar'' program seems to have a limit that does not allow it to generate some of the libraries; in debug mode, three sublibraries (one for 1d, 2d, and 3d, each) have a size of more than 40 MB, and the system ``ar'' errored out with the following message:

      ar: Warning: creating lib/libdeal_II_2d.g.a
      /: write failed, file system is full
      ar:  error writing archive member contents: Bad file number
      gmake: *** [lib/libdeal_II_2d.g.a] Error 1
    
However, it is not true that there is no left space on that device. Furthermore, it is funny that ``ar'' warns about an action that it is told to do. The solution is to install GNU ar from the GNU binutils package, which is available for the OSF operating system as well, even though the GNU assembler gas is not. With GNU ar installed, linking object files together to libraries went fine.

Another problem occured when gcc generated an internal compiler error when compiling the AssertThrow macro. (Note that we have also observed this effect on DEC Alpha stations running Linux instead of OSF.) In order to avoid this problem, on systems where this happens we changed the behaviour of this macro to simply abort the program, instead of throwing an exception. This then does not allow you to catch exceptions that are generated on other systems, but it was the only way we were able to make the compiler work. If anyone should have a better idea, we would be eager to hear about it.

The decisions to use -gstabs over -ggdb, and whether the AssertThrow macro works correctly are done at configure time, and are not hard-coded into the library. Thus, if your system has a patch for the system assembler installed that allows it to accept longer debugging information lines, or if your compiler accepts the AssertThrow macro, then the restrictions above do not apply. If you install a patch to the assembler or the compiler to avoid these problems, re-configure the deal.II library and re-compile it for the changes to take full effect.

As a last note: we have experienced link problems when using the ``squangle'' scheme of the compiler, with version 2.95.2 of the gcc compiler. The resulting error messages look like this:

      /usr/bin/ld:
      Unresolved:
      type_info::operator==(type_info const &) const
      collect2: ld returned 1 exit status
    
These errors are due to the fact that the function type_info::operator==(const typeinfo &) can be squangled into the two strings __eq__C9type_infoRC9type_info and __eq__C9type_infoRCB0 alike, with the same meaning. The latter uses a ``back-reference'' to denote the parameter with the same type as the class (this is the ``B0'' part, identifying the parameter type with the class type), while the first version explicitely lists the parameter type. Of course, the compiler should be consistent in what version it generates, but it is not, unfortunately.

It is possible to work around this bug in the compiler by the following small hack, which you have to compile and link in with all programs that use the type_info::operator==(const typeinfo &) function:

      extern "C" {
        int __eq__C9type_infoRC9type_info (void *x1, void *x2);
        int __eq__C9type_infoRCB0 (void *x1, void *x2) {
          return __eq__C9type_infoRC9type_info(x1,x2);
        };
      };
    
Note that the ``step-7'' example program uses this operator, and therefore needs to be linked with this code snippet. Alternatively, you can insert these lines into one of your source files, if you experience the problems described above.