+++ /dev/null
-<!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>
+++ /dev/null
-<!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>
+++ /dev/null
-<!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>
+++ /dev/null
-<!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> cat t.cc
- class X {
- template <int dim> void f() {};
- template <int dim> void g();
- };
-
- template <int dim>
- void X::g () {
- void (X::*p) () = &X::template f<dim>;
- };
-
- // explicit instantiation
- template void X::g<1> ();
- aixterm7:/u/sfb359/q71> /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<1>()".
- </pre>
- </code>
- </p>
-
- <li> <p>
- A compiler bug prevented us from compiling this snippet:
- <code>
- <pre>
- aixterm7:/u/sfb359/q71> cat t.cc
- namespace std {
- template <class _Ty> class allocator {};
- template<class _Ty, class _Ax = allocator<_Ty> > class vector{};
- }
-
- struct X {};
- template <int dim> void g (const std::vector<X> &x);
-
- void f () {
- std::vector<X> x;
- g<1> (x);
- };
- aixterm7:/u/sfb359/q71> /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 <vector></code>.
- </p>
-
- <li> <p>
- There's another nasty bug that does not allow such code:
- <code>
- <pre>
- aixterm7:/u/sfb359/q71> cat t.cc
- #include <vector>
- class X{};
-
- void f() {
- std::vector<X> v;
- std::vector<X>::iterator i1=v.begin();
- std::vector<X>::const_iterator i2=v.begin();
- bool x = (i1 != i2);
- };
- aixterm7:/u/sfb359/q71> /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<X,int,X *,X &,X *,X &>::operator!=(const _Myt &) const" is not a viable candidate.
- "t.cc", line 8.19: 1540-0256 (I) A parameter of type "const std::_Ptrit<X,int,X *,X &,X *,X &> &" cannot be initialized with an expression of type "std::vector<X,std::allocator<X> >::const_iterator".
- "/usr/vacpp/include/utility", line 59.14: 1540-1283 (I) "template <class _T1, class _T2> std::operator!=(const pair<_T1,_T2> &, const pair<_T1,_T2> &)" is not a viable candidate.
- "/usr/vacpp/include/xutility", line 362.14: 1540-1283 (I) "template <class _RI> std::operator!=(const reverse_iterator<_RI> &, const reverse_iterator<_RI> &)" is not a viable candidate.
- "/usr/vacpp/include/xutility", line 477.14: 1540-1283 (I) "template <class _E, class _Tr> std::operator!=(const istreambuf_iterator<_E,_Tr> &, const istreambuf_iterator<_E,_Tr> &)" is not a viable candidate.
- "/usr/vacpp/include/iterator", line 167.14: 1540-1283 (I) "template <class _Ty, class _E, class _Tr, class _Dist> std::operator!=(const istream_iterator<_Ty,_E,_Tr,_Dist> &, const istream_iterator<_Ty,_E,_Tr,_Dist> &)" is not a viable candidate.
- "/usr/vacpp/include/xmemory", line 127.14: 1540-1283 (I) "template <class _Ty, class _U> std::operator!=(const allocator<_Ty> &, const allocator<_U> &)" is not a viable candidate.
- "/usr/vacpp/include/vector", line 293.14: 1540-1283 (I) "template <class _Ty, class _A> std::operator!=(const vector<_Ty,_A> &, const vector<_Ty,_A> &)" 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<double>" cannot be converted to
- "const Vector<double>".
- </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>
+++ /dev/null
-<!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>
+++ /dev/null
-<!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>
<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>