]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
Delete information about other compilers that has been out of date for years already.
authorbangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Wed, 22 Feb 2012 15:48:41 +0000 (15:48 +0000)
committerbangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Wed, 22 Feb 2012 15:48:41 +0000 (15:48 +0000)
git-svn-id: https://svn.dealii.org/trunk@25149 0785d39b-7218-0410-832d-ea1e28bc413d

deal.II/doc/platforms/bcc.html [deleted file]
deal.II/doc/platforms/dec-osf.html [deleted file]
deal.II/doc/platforms/dec-osf5.html [deleted file]
deal.II/doc/platforms/ibm_aix_xlc.html [deleted file]
deal.II/doc/platforms/sgi-irix.html [deleted file]
deal.II/doc/platforms/windows.html [deleted file]
deal.II/doc/readme.html

diff --git a/deal.II/doc/platforms/bcc.html b/deal.II/doc/platforms/bcc.html
deleted file mode 100644 (file)
index 8778e25..0000000
+++ /dev/null
@@ -1,38 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Readme -- Installation Instructions</title>
-    <meta name="author" content="Wolfgang Bangerth <bangerth@dealii.org>">
-    <meta name="keywords" content="deal.II">
-  </head>
-
-  <body>
-
-
-    <h1>Installation instructions for Borland'c C++ 5.7</h1>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    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.
-    </p>
-
-  </body>
-</html>
diff --git a/deal.II/doc/platforms/dec-osf.html b/deal.II/doc/platforms/dec-osf.html
deleted file mode 100644 (file)
index 71e11d4..0000000
+++ /dev/null
@@ -1,173 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Readme -- Installation Instructions</title>
-    <meta name="author" content="the deal.II authors <authors@dealii.org>">
-    <meta name="keywords" content="deal.II">
-  </head>
-
-  <body>
-
-
-    <h1>Installation instructions for DEC OSF1 V4.0</h1>
-
-
-    <h2>Using DEC's cxx compiler</h2>
-
-    <p>
-    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 <code>cmath</code>,
-    <code>cstdlib</code>, etc, which are included instead of
-    <code>math.h</code>, <code>stdlib.h</code>, etc. Otherwise there
-    did not seem unsurmountable obstacles to the use of that
-    compiler. 
-    </p>
-
-    <p>
-    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.
-    </p>
-
-
-
-    <h2>Using gcc as compiler</h2>
-
-    <p>
-    We have tried to compile <acronym>deal.II</acronym> 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.
-    </p>
-
-    <p>
-    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 <em>squangling</em>, an
-    amalgamation of <em>squeezing</em> and <em>mangling</em>) 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
-    <a href="http://gcc.gnu.org/fom_serv/cache/41.html" target="_top">on 
-    this page</a>. With this scheme switched on, we were able to
-    compile the library.
-    </p>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    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:
-    <pre>
-      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
-    </pre>
-    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.
-    </p>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    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.
-    </p>
-
-
-    <p>
-    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:
-    <pre>
-      /usr/bin/ld:
-      Unresolved:
-      type_info::operator==(type_info const &) const
-      collect2: ld returned 1 exit status
-    </pre>
-    These errors are due to the fact that the function
-    <code class="member">type_info::operator==(const typeinfo &)</code>
-    can be squangled into the two strings
-    <code class="member">__eq__C9type_infoRC9type_info</code> and
-    <code class="member">__eq__C9type_infoRCB0</code> 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.
-    </p>
-
-    <p>
-    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
-    <code class="member">type_info::operator==(const typeinfo &)</code>
-    function:
-    <pre>
-      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);
-        };
-      };
-    </pre>
-    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.
-    </p>
-
-
-
-  </body>
-</html>
diff --git a/deal.II/doc/platforms/dec-osf5.html b/deal.II/doc/platforms/dec-osf5.html
deleted file mode 100644 (file)
index ebfcb5f..0000000
+++ /dev/null
@@ -1,76 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Readme -- Installation Instructions</title>
-    <meta name="author" content="the deal.II authors <authors@dealii.org>">
-    <meta name="keywords" content="deal.II">
-  </head>
-
-  <body>
-
-
-    <h1>Installation instructions for DEC OSF1 V5.x</h1>
-
-    <p>
-    Installation on DEC (now Compaq) OSF1 succeeded mostly for compilation with
-    both gcc2.95 and cxx version 6.3. Some issues remain:
-    <ul>
-    <li> <p>
-         We were not able to create functional shared libraries with
-         cxx; this is most probably due to wrong compilation and link
-         flags and should be solvable by someone with experience with
-         cxx.
-        </p>
-
-    <li> <p>
-         Using static libraries and cxx, the step-4 example program
-         can not be linked. This is due to the fact that it links to
-         the libraries for both 2d and 3d, and the linker reports
-         conflicts for multiply defined symbols
-         <code>__init_sti__tria_cc_776f5f60</code>. These are actually
-         functions automatically generated by the compiler and used to
-         initialize the static data objects in the file
-         <code>tria.cc</code>. As the compiler seems to select the
-         name of this automatically generated function only based on
-         the file name, it chooses the same name in both the 2d and
-         the 3d library, which results in the clash. In effect this
-         means that it is impossible to link programs statically
-         against libraries for more than one space dimension at a
-         time. We do not know how to teach the compiler to choose
-         names differently.
-        </p>
-
-    <li> <p>
-         When compiled with gcc2.95, the step-4 example programs goes
-         into an infinite loop, at the very end of the program, even
-         after the destructors for the two objects in the main
-         functions have run. Having no access to a debugger, the cause
-         is unknown.
-        </p>
-
-    <li> <p>
-         The step-5 example program crashes right after start when
-         compiled with both gcc2.95 and cxx6.3. The cause is unknown.
-        </p>
-
-    <li> <p>
-         In general there seem to be programs that hang after execution
-         (but are not stopped, they actually need computing time). The
-         cause is unknown.
-        </p>
-    </ul>
-    </p>
-
-    <p>
-    To use one or the other compiler, you have to set the
-    <code>CXX</code> environment variable to either <code>g++</code>
-    or <code>cxx</code>. If it is not set, the configuration scripts
-    seems to take <code>g++</code> as compiler. Please also set the
-    <code>CC</code> environment variable to a corresponding C
-    compiler.
-    </p>
-
-  </body>
-</html>
diff --git a/deal.II/doc/platforms/ibm_aix_xlc.html b/deal.II/doc/platforms/ibm_aix_xlc.html
deleted file mode 100644 (file)
index 5c96400..0000000
+++ /dev/null
@@ -1,141 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Readme -- Installation Instructions</title>
-    <meta name="author" content="the deal.II authors <authors@dealii.org>">
-    <meta name="keywords" content="deal.II">
-  </head>
-
-  <body>
-
-
-    <h1>Installation instructions for IBM AIX using the xlC compiler</h1>
-
-    <p>
-    First note that <acronym>deal.II</acronym> 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.
-    </p>
-
-    <p>
-    xlC 5.0 has large problems mainly in the following areas:
-    <ul>
-    <li> <p> 
-         Templatized member functions of classes. We have not been
-         able to explicitely instantiate them, nor to take the address
-         of such functions. For example, the following program fails:
-        </p>
-
-        <p>
-        <code>
-        <pre>
-        aixterm7:/u/sfb359/q71&gt; cat t.cc
-            class X {
-              template &lt;int dim&gt; void f() {};
-              template &lt;int dim&gt; void g();
-            };
-
-            template &lt;int dim&gt; 
-            void X::g () {
-              void (X::*p) () = &amp;X::template f&lt;dim&gt;;
-            };
-
-            // explicit instantiation
-            template void X::g&lt;1&gt; ();
-        aixterm7:/u/sfb359/q71&gt; /usr/vacpp/bin/xlC -c t.cc -o /dev/null
-            "t.cc", line 8.22: 1540-0130 (S) "X::f" is not declared.
-            "t.cc", line 7.6: 1540-0700 (I) The previous message was produced while processing "X::g&lt;1&gt;()".
-        </pre>
-        </code>
-        </p>
-
-    <li> <p>
-         A compiler bug prevented us from compiling this snippet:
-        <code>
-        <pre>
-        aixterm7:/u/sfb359/q71&gt; cat t.cc
-             namespace std {
-               template &lt;class _Ty&gt;                             class allocator {};
-               template&lt;class _Ty, class _Ax = allocator&lt;_Ty&gt; &gt; class vector{};
-             }
-
-             struct X {};
-             template &lt;int dim&gt; void g (const std::vector&lt;X&gt; &x);
-
-             void f ()  {
-               std::vector&lt;X&gt; x;
-               g&lt;1&gt; (x);
-             };
-         aixterm7:/u/sfb359/q71&gt; /usr/vacpp/bin/xlC -c t.cc -o /dev/null
-             "t.cc", line 11.9: 1540-0130 (S) "allocator" is not declared.
-             "t.cc", line 11.9: 1540-0700 (I) The previous message was produced while processing "g".
-        </pre>
-        </code>
-        This also happens when the first four lines declaring the
-        namespace <code>std::</code> are replaced by 
-        <code>#include &lt;vector&gt;</code>.
-        </p>
-
-    <li> <p>
-         There's another nasty bug that does not allow such code:
-        <code>
-        <pre>
-        aixterm7:/u/sfb359/q71&gt; cat t.cc
-             #include &lt;vector&gt;
-             class X{};
-
-             void f() {
-               std::vector&lt;X&gt; v;
-               std::vector&lt;X&gt;::iterator       i1=v.begin();
-               std::vector&lt;X&gt;::const_iterator i2=v.begin();
-               bool x = (i1 != i2);
-             };
-         aixterm7:/u/sfb359/q71&gt; /usr/vacpp/bin/xlC -c t.cc -o /dev/null
-             "t.cc", line 8.16: 1540-0218 (S) The call does not match any parameter list for "operator!=".
-             "/usr/vacpp/include/xutility", line 247.14: 1540-1283 (I) "std::_Ptrit&lt;X,int,X *,X &amp;,X *,X &amp;&gt;::operator!=(const _Myt &amp;) const" is not a viable candidate.
-             "t.cc", line 8.19: 1540-0256 (I) A parameter of type "const std::_Ptrit&lt;X,int,X *,X &amp;,X *,X &amp;&gt; &amp;" cannot be initialized with an expression of type "std::vector&lt;X,std::allocator&lt;X&gt; &gt;::const_iterator".
-             "/usr/vacpp/include/utility", line 59.14: 1540-1283 (I) "template &lt;class _T1, class _T2&gt; std::operator!=(const pair&lt;_T1,_T2&gt; &amp;, const pair&lt;_T1,_T2&gt; &amp;)" is not a viable candidate.
-             "/usr/vacpp/include/xutility", line 362.14: 1540-1283 (I) "template &lt;class _RI&gt; std::operator!=(const reverse_iterator&lt;_RI&gt; &amp;, const reverse_iterator&lt;_RI&gt; &amp;)" is not a viable candidate.
-             "/usr/vacpp/include/xutility", line 477.14: 1540-1283 (I) "template &lt;class _E, class _Tr&gt; std::operator!=(const istreambuf_iterator&lt;_E,_Tr&gt; &amp;, const istreambuf_iterator&lt;_E,_Tr&gt; &amp;)" is not a viable candidate.
-             "/usr/vacpp/include/iterator", line 167.14: 1540-1283 (I) "template &lt;class _Ty, class _E, class _Tr, class _Dist&gt; std::operator!=(const istream_iterator&lt;_Ty,_E,_Tr,_Dist&gt; &amp;, const istream_iterator&lt;_Ty,_E,_Tr,_Dist&gt; &amp;)" is not a viable candidate.
-             "/usr/vacpp/include/xmemory", line 127.14: 1540-1283 (I) "template &lt;class _Ty, class _U&gt; std::operator!=(const allocator&lt;_Ty&gt; &amp;, const allocator&lt;_U&gt; &amp;)" is not a viable candidate.
-             "/usr/vacpp/include/vector", line 293.14: 1540-1283 (I) "template &lt;class _Ty, class _A&gt; std::operator!=(const vector&lt;_Ty,_A&gt; &amp;, const vector&lt;_Ty,_A&gt; &amp;)" is not a viable candidate.
-        </pre>
-        </code>
-        </p>
-
-    <li> <p>
-         Finally, there was a bug (sorry, I can't reproduce it
-         presently in a small code snippet) which yielded this funny
-         error message:
-        <pre>
-        <code>
-             "source/dofs/dof_accessor.cc", line 720.80: 1540-0216 (S) An
-             expression of type "const Vector&lt;double&gt;" cannot be converted to
-             "const Vector&lt;double&gt;". 
-        </pre>
-        </code>
-        </p>
-    </ul>
-    </p>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    xlC version 6.0 does fare a little better, but there are still far too many
-    places to make things work.
-    </p>
-
-  </body>
-</html>
diff --git a/deal.II/doc/platforms/sgi-irix.html b/deal.II/doc/platforms/sgi-irix.html
deleted file mode 100644 (file)
index 62899ae..0000000
+++ /dev/null
@@ -1,83 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Readme -- Installation Instructions</title>
-    <meta name="author" content="the deal.II authors <authors@dealii.org>">
-    <meta name="keywords" content="deal.II">
-  </head>
-
-  <body>
-
-
-    <h1>Installation instructions for SGI IRIX</h1>
-
-    <p>
-    <acronym>deal.II</acronym> works without problems with shared
-    libraries on this platform, if you list the path
-    <code>$D/lib</code> in your <code>$LD_LIBRARY_PATH</code>
-    environment variable, where <code>$D</code> is the path to your
-    installation of the <acronym>deal.II</acronym> library. The
-    necessary actions can be done with the commands
-    <pre>
-    <code>
-      setenv LD_LIBRARY_PATH $D/lib:$LD_LIBRARY_PATH
-    </code>
-    </pre>
-    for csh-like shells, or by
-    <pre>
-    <code>
-      export LD_LIBRARY_PATH=$D/lib:$LD_LIBRARY_PATH
-    </code>
-    </pre>
-    if you use the ``bash'' shell. Please substitute <code>$D</code>
-    by whatever is the appropriate path on your installation.
-    </p>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    We note that this might lead to problems if, for whatever reason,
-    you have multiple versions of <acronym>deal.II</acronym> 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 
-    <a href="../readme.html#configuration-options" target="body">ReadMe</a> file to
-    find out how to do that).
-    </p>
-
-    <p>
-    When compiling <acronym>deal.II</acronym> with the MIPSpro
-    compiler in 64-bit mode it is necessary to
-    <pre>
-    <code>
-      setenv CXXFLAGS -64
-      setenv LDFLAGS -64
-    </code>
-    </pre>
-    before calling <code>./configure</code>.
-    Furthermore, the <code>$LD_LIBRARY64_PATH</code> (instead of the
-    <code>$LD_LIBRARY_PATH</code>) environment variable needs to be set
-    <pre>
-    <code>
-      setenv LD_LIBRARY64_PATH $D/lib:$LD_LIBRARY64_PATH
-    </code>
-    </pre>
-    On ``bash'' shells use the <code>export</code> command accordingly.
-    </p>
-
-  </body>
-</html>
diff --git a/deal.II/doc/platforms/windows.html b/deal.II/doc/platforms/windows.html
deleted file mode 100644 (file)
index ebd9b5c..0000000
+++ /dev/null
@@ -1,43 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
-   "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
-  <head>
-    <link href="../screen.css" rel="StyleSheet" media="screen">
-    <title>The deal.II Readme -- Installation Instructions</title>
-    <meta name="author" content="the deal.II authors <authors@dealii.org>">
-    <meta name="keywords" content="deal.II">
-  </head>
-
-  <body>
-
-
-    <h1>Installation instructions for Microsoft
-           Windows 95/98/2000/NT/XP</h1>
-
-    <p>
-    It is possible to install <acronym>deal.II</acronym> on Microsoft Windows
-    systems as well, using either the <a href="http://www.cygwin.com">Cygwin</a> 
-    or <a href="http://www.mingw.org">MingW</a> 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 <a href="../readme.html" target="body">ReadMe</a>
-    file. Also, you need to include the <code>deal.II/lib</code> path in your PATH 
-    environment variable (e.g. by editing your <code>.bash_profile</code> 
-    file or the Windows registry).
-    </p>
-
-    <p>
-    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.
-    </p>
-
-    <p>
-    For more details, please have a look at the <a href="faq.html#windows">FAQ section</a>.
-    </p>
-
-  </body>
-</html>
index 9568d0c9ff214cb48923b757588ceea4671f97a8..d47c2be2b4da16edafab2924f7e37f01028c834b 100644 (file)
@@ -24,7 +24,6 @@
       <li> <a href="#prerequisites">System requirements</a>
        <ul>
          <li> <a href="#supported">Supported platforms</a>
-         <li> <a href="#unsupported">Unsupported and partly supported platforms</a>
          <li> <a href="#additional-software">Additional software requirements</a>
        </ul>
       <li> <a href="#installation">Installation</a>
     FreeBSD, or Linux on chips like SPARC, PA-RISC, PowerPC, etc) using
     gcc as compiler, but we do not regularly test them.
 
-    <a name="unsupported"></a>
-    <h3>Unsupported / partly supported platforms</h3>
-
-    For the following list of systems, we have collected
-    our experiences on separate pages:
-    <ul>
-      <li> <a href="platforms/sgi-irix.html" target="body">SGI
-           IRIX64</a> with gcc 3.2, 3.3 and 3.4, and with MIPSpro 7.41;
-
-      <li> <a href="platforms/dec-osf5.html" target="body">OSF1 V5.3 on
-           Alpha</a> with gcc newer than 2.95.x (the same notes probably also
-          apply to Linux on DEC Alpha) and using DEC's cxx compiler version
-           6.3; for older systems with OSF1 4.0 and cxx6.0 please see
-          <a href="platforms/dec-osf.html" target="body">this page</a>.
-
-      <li> <a href="platforms/ibm_aix_xlc.html" target="body">IBM AIX
-           with IBM's xlC 5.0 and 6.0 compilers</a>.
-
-      <li> <a href="platforms/windows.html" target="body">Microsoft
-           Windows 95/98/2000/NT/XP</a>.
-
-      <li> <a href="platforms/bcc.html" target="body">Borland C++/Kylix</a>.
-    </ul>
+    <p>
+      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.
     </p>
 
     <p>
     to new systems</a>.
     </p>
 
+
     <a name="additional-software"></a>
     <h3>Additional software requirements</h3>
 

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.