rm -f contrib/config/tests/darwin-dynamic-cast/main
])
-
-
-dnl -------------------------------------------------------------
-dnl On some systems, notably AIX and SUN Solaris, using threads
-dnl leads to warnings since the POSIX_MUTEX_INITIALIZER preprocessor
-dnl variable used to initialize POSIX mutex objects does not contain
-dnl initializers for all elements of the mutex. This is not wrong,
-dnl but leads to the message "warning: aggregate has a partly
-dnl bracketed initializer", which is annoying since it shows up
-dnl _very_ often in our files, although this is something that
-dnl happens inside gcc systems headers. So avoid the warning if
-dnl necessary
-dnl
-dnl Usage:
-dnl DEAL_II_CHECK_CHECK_PARTLY_BRACKETED_INITIALIZER
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_PARTLY_BRACKETED_INITIALIZER, dnl
-[
- if test "$enablethreads" = yes ; then
- case "$GXX_VERSION" in
- gcc*)
- AC_MSG_CHECKING(for only partly bracketed mutex initializer)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG -Werror"
- AC_TRY_COMPILE(
- [
-# include <vector>
- ],
- [;],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes)
- CXXFLAGSG="$CXXFLAGSG -Wno-missing-braces"
- CXXFLAGSO="$CXXFLAGSO -Wno-missing-braces"
- ])
- ;;
- *)
- ;;
- esac
- fi
-])
-
-
-
-dnl -------------------------------------------------------------
-dnl On SunOS 4.x, the `getrusage' function exists, but is not declared
-dnl in the respective header file `resource.h', as one would think when
-dnl reading the man pages. Then we have to declare this function
-dnl ourselves in those files that use this function. The question whether
-dnl we have to do so is controlled by a preprocessor variable.
-dnl
-dnl If the function is not properly declared, then set the preprocessor
-dnl variable NO_HAVE_GETRUSAGE
-dnl
-dnl Usage: DEAL_II_CHECK_GETRUSAGE
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_GETRUSAGE, dnl
-[
- AC_MSG_CHECKING(whether getrusage is properly declared)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- AC_TRY_COMPILE(
- [
-#include <sys/resource.h>
- ],
- [
- rusage *ru;
- getrusage(RUSAGE_SELF,ru);
- ],
- [
- AC_MSG_RESULT(yes)
- ],
- [
- AC_MSG_RESULT(no)
- AC_DEFINE(NO_HAVE_GETRUSAGE, 1,
- [On SunOS 4.x, the getrusage() function exists, but
- is not declared in the respective header file
- <resource.h>, as one would think when reading the
- man pages. Then we have to declare this function
- ourselves in those files that use this function.
- The question whether we have to do so is controlled
- by the preprocessor variable.])
- ])
-]
-)
-
-
-
-
-dnl -------------------------------------------------------------
-dnl Sun's Forte compiler (at least up to the Version 7 Early Access
-dnl release) has a problem with the following code, when compiling
-dnl with debug output:
-dnl
-dnl /* ---------------------------------------------------------- */
-dnl /* Internal compiler error in abi2_mangler::entity_expression */
-dnl /* when compiled with -g. */
-dnl template < int dim > struct T {
-dnl typedef T<dim-1> SubT;
-dnl T (SubT);
-dnl };
-dnl
-dnl template <int dim> T<dim>::T (SubT) {};
-dnl
-dnl template class T<3> ;
-dnl /* ---------------------------------------------------------- */
-dnl
-dnl The compiler gets an internal compiler error, so we work around
-dnl this problem by a really evil hack in the sources.
-dnl
-dnl Usage: DEAL_II_CHECK_LOCAL_TYPEDEF_COMP
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_LOCAL_TYPEDEF_COMP, dnl
-[
- AC_MSG_CHECKING(for local computed template typedef bug)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG -g"
- AC_TRY_COMPILE(
- [
- template < int dim > struct T {
- typedef T<dim-1> SubT;
- T (SubT);
- };
-
- template <int dim> T<dim>::T (SubT) {}
-
- template class T<3>;
- ],
- [],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes. using workaround)
- AC_DEFINE(DEAL_II_LOCAL_TYPEDEF_COMP_WORKAROUND, 1,
- [Define if we have to work around a bug in Sun's Forte compiler.
- See the aclocal.m4 file in the top-level directory for a
- description of this bug.])
- ])
-])
-
-
-
-dnl -------------------------------------------------------------
-dnl Sun's Forte compiler (at least up to the Version 7 Early Access
-dnl release) have a problem with the following code, when compiling
-dnl with debug output:
-dnl
-dnl /* ----------------------------------------------- */
-dnl /* Problem 14: Access control. Friendship is not */
-dnl /* granted although explicitly declared. */
-dnl template <int N, int M> class T { int bar (); };
-dnl
-dnl template <int M> class T<1,M> {
-dnl private:
-dnl static int i;
-dnl template <int N1, int N2> friend class T;
-dnl };
-dnl
-dnl template <int N,int M> int T<N,M>::bar () {
-dnl return T<N-1,M>::i;
-dnl };
-dnl
-dnl template class T<2,1> ;
-dnl /* ---------------------------------------------------------- */
-dnl
-dnl The compiler does not allow access to T<1,1>::i, although the
-dnl accessing class is explicitly marked friend.
-dnl
-dnl Usage: DEAL_II_CHECK_TEMPLATE_SPEC_ACCESS
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_TEMPLATE_SPEC_ACCESS, dnl
-[
- AC_MSG_CHECKING(for partially specialized template access control bug)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- AC_TRY_COMPILE(
- [
- template <int N, int M> struct T { int bar (); };
-
- template <int M> struct T<1,M> {
- T ();
- private:
- static int i;
- template <int N1, int N2> friend class T;
- };
-
- template <int N,int M> int T<N,M>::bar () {
- return T<N-1,M>::i;
- }
-
- template class T<2,1>;
- ],
- [],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes. using workaround)
- AC_DEFINE(DEAL_II_TEMPLATE_SPEC_ACCESS_WORKAROUND, 1,
- [Define if we have to work around a bug in Sun's Forte compiler.
- See the aclocal.m4 file in the top-level directory for a
- description of this bug.])
- ])
-])
-
-
-
dnl -------------------------------------------------------------
dnl In some cases, we would like to name partial specializations
dnl as friends. However, the standard forbids us to do so. But
-dnl -------------------------------------------------------------
-dnl DEC/Compaq's cxx compiler does not want us to implement
-dnl virtual functions that were declared abstract before. We do
-dnl this with the destructor of the Function class, since we want
-dnl to avoid people making objects of that class, but all functions
-dnl have default implementations, so the class is not abstract
-dnl without that. Since every derived class has a destructor, it
-dnl is sufficient to mark the destructor =0.
-dnl
-dnl Unfortunately, cxx refuses to grok that. It sees the respective
-dnl function in the .cc file, but does not instantiate it, leading
-dnl to linker errors. Thus, check this misfeature, and if present
-dnl simply do not mark the function abstract for this particular
-dnl compiler.
-dnl
-dnl Usage: DEAL_II_CHECK_IMPLEMENTED_PURE_FUNCTION_BUG
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_IMPLEMENTED_PURE_FUNCTION_BUG, dnl
-[
- AC_MSG_CHECKING(for bug with implementing pure functions)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- AC_TRY_COMPILE(
- [
- template <int dim>
- struct Function
- {
- public:
- virtual ~Function () = 0;
- };
-
- template <int dim>
- Function<dim>::~Function ()
- {}
-
- template class Function<1>;
- template Function<1>::~Function();
- ],
- [],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes. using workaround)
- AC_DEFINE(DEAL_II_IMPLEMENTED_PURE_FUNCTION_BUG, 1,
- [Defined if the compiler refuses to compile the definition
- of a function that was previously declared abstract.])
- ])
-])
-
-
-
-dnl -------------------------------------------------------------
-dnl Many compilers get this wrong (see Section 14.7.3.1, number (4)):
-dnl ---------------------------------
-dnl template <int dim> struct T {
-dnl static const int i;
-dnl };
-dnl
-dnl template <> const int T<1>::i;
-dnl template <> const int T<1>::i = 1;
-dnl ---------------------------------
-dnl First, by Section 14.7.3.14 of the standard, the first template<>
-dnl line must necessarily be the _declaration_ of a specialization,
-dnl and the second is then its definition. There is therefore no
-dnl reason to report a doubly defined variable (Intel ICC 6.0), or
-dnl to choke on these lines at all (Sun Forte)
-dnl
-dnl Usage: DEAL_II_CHECK_MEMBER_VAR_SPECIALIZATION_SPEC_BUG
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_MEMBER_VAR_SPECIALIZATION_BUG, dnl
-[
- AC_MSG_CHECKING(for member variable specialization bug)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- AC_TRY_COMPILE(
- [
- template <int dim> struct T {
- static const int i;
- };
-
- template <> const int T<1>::i;
- template <> const int T<1>::i = 1;
- ],
- [],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes. using workaround)
- AC_DEFINE(DEAL_II_MEMBER_VAR_SPECIALIZATION_BUG, 1,
- [Defined if the compiler refuses to allow the
- explicit specialization of static member
- variables. For the exact failure mode, look at
- aclocal.m4 in the top-level directory.])
- ])
-])
-
-
-
dnl -------------------------------------------------------------
dnl This is a variant of the previous test. Some icc 11.0
dnl builds (sub-releases) on Windows apparently don't allow
])
-
-dnl -------------------------------------------------------------
-dnl A third test: MIPSpro gives a bogus warning about unused code
-dnl on code that is clearly used, when inline member functions
-dnl are in classes in anonymous namespaces. Check for this to allow
-dnl us to work around this problem
-dnl
-dnl Usage: DEAL_II_CHECK_ANON_NAMESPACE_BUG3
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_ANON_NAMESPACE_BUG3, dnl
-[
- AC_MSG_CHECKING(for bogus warning with anonymous namespaces)
-
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- case "$GXX_VERSION" in
- gcc*)
- CXXFLAGS="$CXXFLAGSG -Werror"
- ;;
-
- MIPSpro*)
- CXXFLAGS="$CXXFLAGSG -diag_error 1174"
- ;;
- esac
-
- AC_TRY_COMPILE(
- [
- template<int dim> class Point
- {
- public:
- Point() {};
- };
-
- class GridTools {
- public:
- template <int dim> static void shift (const Point<dim> &s);
-
- template <typename Predicate>
- static void transform (const Predicate &predicate);
- };
-
- namespace {
- template <int dim> class ShiftPoint {
- public:
- ShiftPoint (const Point<dim> &) {};
- void g() const;
- };
-
- template<int dim> void ShiftPoint<dim>::g() const {}
- }
-
- template <typename Predicate>
- void GridTools::transform (const Predicate &predicate)
- { predicate.g(); }
-
- template <int dim>
- void GridTools::shift (const Point<dim> &s)
- { transform (ShiftPoint<dim>(s)); }
-
- template void GridTools::shift (const Point<1> &);
- ],
- [
- ;
- ],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes)
- AC_DEFINE_UNQUOTED(DEAL_II_ANON_NAMESPACE_BOGUS_WARNING, 1,
- [Flag indicating whether there is a bug in the
- compiler that leads to bogus warnings for
- inline class members in anonymous namespaces])
- ])
-])
-
-
-
-dnl -------------------------------------------------------------
-dnl A test to identify Apples buggy gcc3.3 version. If the
-dnl explicit instantiations are placed at the end of a source
-dnl file, sometimes only weak symbols are generated, which
-dnl lead to linker problems.
-dnl For more information, see
-dnl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24331
-dnl As this bug can be easily avoided by applying the
-dnl "november2004gccupdate" Patch which can be found
-dnl on http://www.apple.com/developer, this check will
-dnl only produce a warning at the end of the configuration
-dnl process.
-dnl
-dnl Usage: DEAL_II_CHECK_WEAK_LINKAGE_BUG
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_WEAK_LINKAGE_BUG, dnl
-[
- DARWIN_GCC_WEAK_LINKAGE_BUG="no"
- case "$target" in
- *-apple-darwin* )
-
- AC_MSG_CHECKING(for weak linkage bug (Apple gcc3.3) )
-
- dnl Create 1st testfile
- echo "template <int> void SYMBOL() {}" > conftest.cc
- echo "int g() { SYMBOL<1> (); }" >> conftest.cc
- echo "template void SYMBOL<1> ();" >> conftest.cc
-
- dnl Compile it
- $CXX -c conftest.cc -o conftest.$ac_objext
-
- dnl and write symbols to file 1
- nm conftest.$ac_objext | grep SYMBOL > symb1
-
- dnl Create 2nd testfile
- echo "template <int> void SYMBOL() {}" > conftest.cc
- echo "template void SYMBOL<1> ();" >> conftest.cc
- echo "int g() { SYMBOL<1> (); }" >> conftest.cc
-
- dnl Compile it
- $CXX -c conftest.cc -o conftest.$ac_objext
-
- dnl and write symbols to file 2
- nm conftest.$ac_objext | grep SYMBOL > symb2
-
- dnl Compare the relevant symbols. According to the C++
- dnl standard, both source codes should produce the
- dnl same symbols.
- check="`diff symb1 symb2`"
-
- dnl Then try to link everything
- if test "x$check" = "x" ;
- then
- AC_MSG_RESULT(no)
- else
- AC_MSG_RESULT(yes)
- DARWIN_GCC_WEAK_LINKAGE_BUG="yes"
- AC_DEFINE(DEAL_II_WEAK_LINKAGE_BUG, 1,
- [This error appears in the Apple edition of the
- gcc 3.3, which ships with Darwin7.9.0 and
- probably previous version. It leads to
- problems during linking.
- For the details, look at aclocal.m4 in the
- top-level directory.])
- fi
- rm -f conftest.$ac_objext
- rm -f symb1 symb2
- ;;
- esac
-])
-
-
-
dnl -------------------------------------------------------------
dnl We have so many templates in deal.II that sometimes we need
dnl to make it clear with which types a template parameter can
-
-dnl -------------------------------------------------------------
-dnl Old versions of gcc had a problem with arrays inside ?:
-dnl expressions: they decayed too quickly to pointers. This then
-dnl leads to erroneous warnings :-(
-dnl
-dnl Usage: DEAL_II_CHECK_ARRAY_CONDITIONAL_DECAY_BUG
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_ARRAY_CONDITIONAL_DECAY_BUG, dnl
-[
- AC_MSG_CHECKING(for array assignment in conditional bug)
- AC_LANG(C++)
- CXXFLAGS="-W -Wall -Werror"
- AC_TRY_COMPILE(
- [
- ],
- [
- const int x[2][2] = {{1,1},{1,1}};
- const int (&y)[2] = (1 ? x[0] : x[1]);
- return y[0];
- ],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes)
- AC_DEFINE(DEAL_II_ARRAY_CONDITIONAL_DECAY_BUG, 1,
- [Defined if the compiler has a problem with
- assigning arrays in conditionals])
- ])
-])
-
-
-
dnl -------------------------------------------------------------
dnl Some versions of gcc get this example wrong:
dnl ---------------------------------
-dnl -------------------------------------------------------------
-dnl Some older versions of GCC (3.x series) have trouble with a
-dnl certain part of the BOOST GRAPH library, yielding errors of
-dnl the kind "sorry, unimplemented: use of `enumeral_type' in
-dnl template type unification".
-dnl
-dnl Usage: DEAL_II_CHECK_BOOST_GRAPH_COMPILER_BUG
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_BOOST_GRAPH_COMPILER_BUG, dnl
-[
- if test "x$GXX" = "xyes" ; then
- AC_MSG_CHECKING(for boost::graph compiler internal error)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSO $BOOST_INCLUDE_DIR"
- AC_TRY_COMPILE(
- [
-#include <boost/graph/adjacency_list.hpp>
-#include <boost/graph/properties.hpp>
-
-namespace types
-{
- using namespace boost;
-
- typedef adjacency_list<vecS, vecS, undirectedS,
- property<vertex_color_t, default_color_type,
- property<vertex_degree_t,int> > > Graph;
-}
-
-void create_graph (types::Graph)
-{}
- ],
- [
- ],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes)
- AC_DEFINE(DEAL_II_BOOST_GRAPH_COMPILER_BUG, 1,
- [Defined if the compiler gets an internal error compiling
- some code that involves boost::graph])
- ])
- fi
-])
-
-
-
-dnl -------------------------------------------------------------
-dnl The boost::shared_ptr class has a templated assignment operator
-dnl but no assignment operator matching the default operator
-dnl signature (this if for boost 1.29 at least). So when using
-dnl using a normal assignment between identical types, the
-dnl compiler synthesizes teh default operator, rather than using
-dnl the template. It doesn't matter here, but is probably an
-dnl oversight on behalf of the operators. It should be fixed in newer
-dnl versions of boost.
-dnl
-dnl With -Wsynth in gcc we then get a warning. So if we find that
-dnl this is still the case, disable -Wsynth, i.e. remove it from
-dnl the list of warning flags.
-dnl
-dnl Usage: DEAL_II_CHECK_BOOST_SHARED_PTR_ASSIGNMENT
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_BOOST_SHARED_PTR_ASSIGNMENT, dnl
-[
- if test "x$GXX" = "xyes" ; then
- AC_MSG_CHECKING(for boost::shared_ptr assignment operator= template buglet)
- AC_LANG(C++)
- CXXFLAGS="-Wsynth -Werror"
- AC_TRY_COMPILE(
- [
-# include <boost/shared_ptr.hpp>
- ],
- [
- boost::shared_ptr<int> a,b;
- a = b;
- ],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes)
- CXXFLAGSG="`echo $CXXFLAGSG | perl -pi -e 's/-Wsynth\s*//g;'`"
- ])
- fi
-])
-
-
-
dnl -------------------------------------------------------------
dnl Some versions of icc on some platforms issue a lot of warnings
dnl about the unreliability of floating point comparisons. Check
])
-dnl -------------------------------------------------------------
-dnl Some test, but for the icc C compiler.
-dnl
-dnl Usage: DEAL_II_ICC_C_WD_1572
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_ICC_C_WD_1572, dnl
-[
- AC_MSG_CHECKING(whether -wd1572 is allowed for the C compiler)
- AC_LANG(C)
- OLDCFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS -wd1572"
- AC_TRY_COMPILE( [], [],
- [
- AC_MSG_RESULT(yes)
- dnl Keep -wd1572 in CFLAGS
- ],
- [
- AC_MSG_RESULT(no)
-
- dnl Remove -wd1572 again from flags
- CFLAGS="$OLDCFLAGS"
- ])
-])
-
-
-
-
-dnl -------------------------------------------------------------
-dnl On some Cygwin systems, a system header file includes this
-dnl preprocessor define:
-dnl #define quad quad_t
-dnl This is of course silly, but beyond that it also hurts as
-dnl since we have member functions and variables with that name
-dnl and we get compile errors depending or not we have this
-dnl particular header file included.
-dnl
-dnl Fortunately, the define is only active is _POSIX_SOURCE is
-dnl not set, so check for this define, and if necessary set
-dnl this flag. We check on all systems, since maybe there are
-dnl other such systems elsewhere...
-dnl
-dnl Usage: DEAL_II_CHECK_QUAD_DEFINE
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_QUAD_DEFINE, dnl
-[
- AC_MSG_CHECKING(for quad vs. quad_t define)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- AC_TRY_COMPILE(
- [
-#include <sys/types.h>
-#if defined(quad)
- no good system;
-#endif
- ],
- [
- ],
- [
- AC_MSG_RESULT(no)
- ],
- [
- AC_MSG_RESULT(yes. working around)
- CXXFLAGSG="$CXXFLAGSG -D_POSIX_SOURCE"
- CXXFLAGSO="$CXXFLAGSO -D_POSIX_SOURCE"
- ])
-])
-
-
-
-dnl -------------------------------------------------------------
-dnl On DEC OSF1, when we specify "-std strict_ansi", we can include
-dnl errno.h, and still not get the definition of the error codes
-dnl such as EINTR, EPIPE, etc.
-dnl
-dnl In this case, use a workaround by explicitly including
-dnl /usr/include/errno.h, instead of just errno.h, which the compiler
-dnl maps to one of its own C/C++ compatibility headers, which only
-dnl define 3 error codes (for reasons unknown)
-dnl
-dnl Usage: DEAL_II_CHECK_ERROR_CODES_DEFINITION
-dnl
-dnl -------------------------------------------------------------
-AC_DEFUN(DEAL_II_CHECK_ERROR_CODES_DEFINITION, dnl
-[
- AC_MSG_CHECKING(for definitions of error codes in errno.h)
- AC_LANG(C++)
- CXXFLAGS="$CXXFLAGSG"
- AC_TRY_COMPILE(
- [
-#include <iostream>
-#include <errno.h>
-using namespace std;
- ],
- [
- cout << EINTR << endl;
- ],
- [
- AC_MSG_RESULT(yes)
- ],
- [
- AC_MSG_RESULT(no. working around)
- AC_DEFINE(DEAL_II_USE_DIRECT_ERRNO_H, 1,
- [Define if the compiler provides a <errno.g> header file
- which does not define all error codes such as EINTR. In
- that case, use the system include file at /usr/include
- instead. There is probably a better way to do this, but
- it is not apparent by looking at the C/C++ compatibility
- header provided by the compiler.])
- ])
-])
-
-
dnl -------------------------------------------------------------
dnl Check whether socket functions (i.e. functions using the