From: bangerth Date: Wed, 22 Feb 2012 15:48:41 +0000 (+0000) Subject: Delete information about other compilers that has been out of date for years already. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e7fcaea2dea2ac7d7229876607110fd8c54cdfe0;p=dealii-svn.git Delete information about other compilers that has been out of date for years already. git-svn-id: https://svn.dealii.org/trunk@25149 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/platforms/bcc.html b/deal.II/doc/platforms/bcc.html deleted file mode 100644 index 8778e25cf4..0000000000 --- a/deal.II/doc/platforms/bcc.html +++ /dev/null @@ -1,38 +0,0 @@ - - - - - The deal.II Readme -- Installation Instructions - - - - - - - -

Installation instructions for Borland'c C++ 5.7

- -

- This compiler is not supported yet, or maybe we should say this - differently: this compiler has a lot of quirks which makes it reject - the library at too many places for us to find workarounds. It has a number - of problems which seem to happen randomly -- trying to cut down on the code - makes them go away, so that it is hard to come up with short testcases. -

- -

- Roughly estimated, there may be about 5 to 10 bugs in the compiler that - prevent it to compile the library. I think one can say that it is close, - but not there yet. -

- -

- However, the compiler is detected by the configuration machinery, so - testing newer versions of the compiler should be simple once they are - released. Borland C++ 5.7 is part of both Borland's Windows C++ compiler - kit as well as the Kylix3 environment for Linux. -

- - - diff --git a/deal.II/doc/platforms/dec-osf.html b/deal.II/doc/platforms/dec-osf.html deleted file mode 100644 index 71e11d4360..0000000000 --- a/deal.II/doc/platforms/dec-osf.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - The deal.II Readme -- Installation Instructions - - - - - - - -

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

- - - - - diff --git a/deal.II/doc/platforms/dec-osf5.html b/deal.II/doc/platforms/dec-osf5.html deleted file mode 100644 index ebfcb5f9ae..0000000000 --- a/deal.II/doc/platforms/dec-osf5.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - - The deal.II Readme -- Installation Instructions - - - - - - - -

Installation instructions for DEC OSF1 V5.x

- -

- Installation on DEC (now Compaq) OSF1 succeeded mostly for compilation with - both gcc2.95 and cxx version 6.3. Some issues remain: -

-

- -

- To use one or the other compiler, you have to set the - CXX environment variable to either g++ - or cxx. If it is not set, the configuration scripts - seems to take g++ as compiler. Please also set the - CC environment variable to a corresponding C - compiler. -

- - - diff --git a/deal.II/doc/platforms/ibm_aix_xlc.html b/deal.II/doc/platforms/ibm_aix_xlc.html deleted file mode 100644 index 5c96400c92..0000000000 --- a/deal.II/doc/platforms/ibm_aix_xlc.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - The deal.II Readme -- Installation Instructions - - - - - - - -

Installation instructions for IBM AIX using the xlC compiler

- -

- First note that deal.II does not work with neither - IBM xlC compiler version 5.0 nor 6.0, i.e. the compiler from the Visual - Age for C++ package. We have tried to make it run and have fixed - as many places as possible in order to reduce the number of - errors, but have not been able to work around some problems. -

- -

- xlC 5.0 has large problems mainly in the following areas: -

-

- -

- At this point, I gave up. In summary, there may have only been half - a dozen bugs in the compiler that were triggered several hundred - times, but as long as these are not fixed in the compiler itself, - I see no way to use xlC for deal.II. Nevertheless, as gcc also - runs on this platform, there is an alternative which you can fall - back on. -

- -

- xlC version 6.0 does fare a little better, but there are still far too many - places to make things work. -

- - - diff --git a/deal.II/doc/platforms/sgi-irix.html b/deal.II/doc/platforms/sgi-irix.html deleted file mode 100644 index 62899ae4ac..0000000000 --- a/deal.II/doc/platforms/sgi-irix.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - The deal.II Readme -- Installation Instructions - - - - - - - -

Installation instructions for SGI IRIX

- -

- deal.II works without problems with shared - libraries on this platform, if you list the path - $D/lib in your $LD_LIBRARY_PATH - environment variable, where $D is the path to your - installation of the deal.II library. The - necessary actions can be done with the commands - 

-    
-      setenv LD_LIBRARY_PATH $D/lib:$LD_LIBRARY_PATH
-    
-
- for csh-like shells, or by - 
-    
-      export LD_LIBRARY_PATH=$D/lib:$LD_LIBRARY_PATH
-    
-
- if you use the ``bash'' shell. Please substitute $D - by whatever is the appropriate path on your installation. -

- -

- These actions are necessary, since on SGI IRIX it seems not - possible to link a program to a shared library by giving the full - path of the latter. On all other systems where we use shared - libraries, the full path to the shared library is given on the - command line and stored somewhere in the executable, so that the - linker finds the library irrespective of the fact that the path is - specified in LD_LIBRARY_PATH or not. However, on SGI IRIX, as it - seems, only the library's name, not its path seems to be stored in - the executable, so LD_LIBRARY_PATH has to be modified. -

- -

- We note that this might lead to problems if, for whatever reason, - you have multiple versions of deal.II installed - and compiled with different flags; then, to ensure that you link - to the correct library at execution time, you will have to - redefine LD_LIBRARY_PATH before execution of your program. Another - possibility would be to used statically linked libraries instead - of shared ones (see the - ReadMe file to - find out how to do that). -

- -

- When compiling deal.II with the MIPSpro - compiler in 64-bit mode it is necessary to - 

-    
-      setenv CXXFLAGS -64
-      setenv LDFLAGS -64
-    
-
- before calling ./configure. - Furthermore, the $LD_LIBRARY64_PATH (instead of the - $LD_LIBRARY_PATH) environment variable needs to be set - 
-    
-      setenv LD_LIBRARY64_PATH $D/lib:$LD_LIBRARY64_PATH
-    
-
- On ``bash'' shells use the export command accordingly. -

- - - diff --git a/deal.II/doc/platforms/windows.html b/deal.II/doc/platforms/windows.html deleted file mode 100644 index ebd9b5c077..0000000000 --- a/deal.II/doc/platforms/windows.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - The deal.II Readme -- Installation Instructions - - - - - - - -

Installation instructions for Microsoft - Windows 95/98/2000/NT/XP

- -

- It is possible to install deal.II on Microsoft Windows - systems as well, using either the Cygwin - or MingW environments - that provide most of the Unix like features for the Windows system - as well (such as ``perl'', or ``make''). You simply have to run the - ``./configure'' script on the shell and follow the installation - instructions in the ReadMe - file. Also, you need to include the deal.II/lib path in your PATH - environment variable (e.g. by editing your .bash_profile - file or the Windows registry). -

- -

- As far as we know, the only point to consider is that you - can't use the ``make'' distributed with MingW, but have to - use the GNU ``make'' from CygWin. If you should encounter other - problems, we would love to hear about it and will try to provide - fixes for them. -

- -

- For more details, please have a look at the FAQ section. -

- - - diff --git a/deal.II/doc/readme.html b/deal.II/doc/readme.html index 9568d0c9ff..d47c2be2b4 100644 --- a/deal.II/doc/readme.html +++ b/deal.II/doc/readme.html @@ -24,7 +24,6 @@
  • System requirements
  • Installation @@ -84,29 +83,13 @@ FreeBSD, or Linux on chips like SPARC, PA-RISC, PowerPC, etc) using gcc as compiler, but we do not regularly test them. - -

    Unsupported / partly supported platforms

    - - For the following list of systems, we have collected - our experiences on separate pages: - +

    + There are of course many other C++ compilers out there though + they seem to become fewer and fewer. Our experience is that with + most of them some part or other of the C++ standard is not + supported and they eventually fail on a project as large as + deal.II. Some may in fact work if one puts in enough time, but + your best bet is probably to stick with the ones listed above.

    @@ -118,6 +101,7 @@ to new systems.

    +

    Additional software requirements