2006-02-05 04:28:05 +03:00
|
|
|
dnl -*- shell-script -*-
|
|
|
|
|
dnl
|
|
|
|
|
dnl Copyright (c) 2004-2006 The Trustees of Indiana University and Indiana
|
|
|
|
|
dnl University Research and Technology
|
|
|
|
|
dnl Corporation. All rights reserved.
|
|
|
|
|
dnl $COPYRIGHT$
|
|
|
|
|
dnl
|
|
|
|
|
dnl Additional copyrights may follow
|
|
|
|
|
dnl
|
|
|
|
|
dnl $HEADER$
|
|
|
|
|
dnl
|
|
|
|
|
|
Another project that has been brewing for a week or so...
We have repeatedly seen users inadvertantly try to use a C compiler
for $CXX (e.g., using icc instead of icpc in recent versions of the
Intel compiler). Unfortunately, this would "sorta work", meaning that
configure would complete successfully and the build would fail much
later in the process (when $CXX was used to try to link a C++
compiler). This was further compounded by the fact that many C
compilers will switch into "C++ mode" when they compile files that end
in .cc -- meaning that they'll *compile* C++ codes properly, but they
won't *link* properly. Hence, users would get all the way down to
compiling the C++ MPI bindings or ompi_info (i.e., very late in the
build process) before the problem became evident.
We already have a test in configure that tries to compile, link, and
run a sample C++ program. This helped ensure that $CXX was a valid
compiler, but it did not catch if the user accidentally supplied a C
compiler instead of a C++ compiler because the test program was simply
"return 0". This commit updates the test program to use some
C++-specific constructs (std::string) so that if the user supplies a C
compiler in $CXX, the program may *compile*, but it will definitely
fail to *link*.
Hence, the process will fail early in configure (with a descriptive
message about how the compiler failed to work properly) rather than
late in the build.
This commit was SVN r10829.
2006-07-15 14:27:09 +04:00
|
|
|
# OMPI_CHECK_COMPILER_WORKS(language, headers, body,
|
2006-02-05 04:28:05 +03:00
|
|
|
# [action-if-found], [action-if-not-found])
|
|
|
|
|
# ----------------------------------------------------
|
Another project that has been brewing for a week or so...
We have repeatedly seen users inadvertantly try to use a C compiler
for $CXX (e.g., using icc instead of icpc in recent versions of the
Intel compiler). Unfortunately, this would "sorta work", meaning that
configure would complete successfully and the build would fail much
later in the process (when $CXX was used to try to link a C++
compiler). This was further compounded by the fact that many C
compilers will switch into "C++ mode" when they compile files that end
in .cc -- meaning that they'll *compile* C++ codes properly, but they
won't *link* properly. Hence, users would get all the way down to
compiling the C++ MPI bindings or ompi_info (i.e., very late in the
build process) before the problem became evident.
We already have a test in configure that tries to compile, link, and
run a sample C++ program. This helped ensure that $CXX was a valid
compiler, but it did not catch if the user accidentally supplied a C
compiler instead of a C++ compiler because the test program was simply
"return 0". This commit updates the test program to use some
C++-specific constructs (std::string) so that if the user supplies a C
compiler in $CXX, the program may *compile*, but it will definitely
fail to *link*.
Hence, the process will fail early in configure (with a descriptive
message about how the compiler failed to work properly) rather than
late in the build.
This commit was SVN r10829.
2006-07-15 14:27:09 +04:00
|
|
|
# Try to compile and run a simple application in 'language'. A
|
|
|
|
|
# warning is always printed if the application fails to run.
|
|
|
|
|
# Action-if-found is evaluated if the application runs successfully
|
|
|
|
|
# (or compiles if cross-compiling), and action-if-not-found is
|
|
|
|
|
# evaluated if the application fails to run.
|
2006-02-05 04:28:05 +03:00
|
|
|
#
|
Another project that has been brewing for a week or so...
We have repeatedly seen users inadvertantly try to use a C compiler
for $CXX (e.g., using icc instead of icpc in recent versions of the
Intel compiler). Unfortunately, this would "sorta work", meaning that
configure would complete successfully and the build would fail much
later in the process (when $CXX was used to try to link a C++
compiler). This was further compounded by the fact that many C
compilers will switch into "C++ mode" when they compile files that end
in .cc -- meaning that they'll *compile* C++ codes properly, but they
won't *link* properly. Hence, users would get all the way down to
compiling the C++ MPI bindings or ompi_info (i.e., very late in the
build process) before the problem became evident.
We already have a test in configure that tries to compile, link, and
run a sample C++ program. This helped ensure that $CXX was a valid
compiler, but it did not catch if the user accidentally supplied a C
compiler instead of a C++ compiler because the test program was simply
"return 0". This commit updates the test program to use some
C++-specific constructs (std::string) so that if the user supplies a C
compiler in $CXX, the program may *compile*, but it will definitely
fail to *link*.
Hence, the process will fail early in configure (with a descriptive
message about how the compiler failed to work properly) rather than
late in the build.
This commit was SVN r10829.
2006-07-15 14:27:09 +04:00
|
|
|
# headers are any headers needed to compile the body (e.g., #include
|
|
|
|
|
# statements), and body is the program to compile. It should include
|
|
|
|
|
# a clean exit from the application (e.g., "return 0" in C/C++, empty in
|
|
|
|
|
# fortran).
|
2006-02-05 04:28:05 +03:00
|
|
|
AC_DEFUN([OMPI_CHECK_COMPILER_WORKS],
|
|
|
|
|
[ AS_VAR_PUSHDEF([lang_var], [ompi_cv_$1_works])
|
|
|
|
|
|
|
|
|
|
AC_CACHE_CHECK([if $1 compiler works], lang_var,
|
|
|
|
|
[AC_LANG_PUSH($1)
|
Another project that has been brewing for a week or so...
We have repeatedly seen users inadvertantly try to use a C compiler
for $CXX (e.g., using icc instead of icpc in recent versions of the
Intel compiler). Unfortunately, this would "sorta work", meaning that
configure would complete successfully and the build would fail much
later in the process (when $CXX was used to try to link a C++
compiler). This was further compounded by the fact that many C
compilers will switch into "C++ mode" when they compile files that end
in .cc -- meaning that they'll *compile* C++ codes properly, but they
won't *link* properly. Hence, users would get all the way down to
compiling the C++ MPI bindings or ompi_info (i.e., very late in the
build process) before the problem became evident.
We already have a test in configure that tries to compile, link, and
run a sample C++ program. This helped ensure that $CXX was a valid
compiler, but it did not catch if the user accidentally supplied a C
compiler instead of a C++ compiler because the test program was simply
"return 0". This commit updates the test program to use some
C++-specific constructs (std::string) so that if the user supplies a C
compiler in $CXX, the program may *compile*, but it will definitely
fail to *link*.
Hence, the process will fail early in configure (with a descriptive
message about how the compiler failed to work properly) rather than
late in the build.
This commit was SVN r10829.
2006-07-15 14:27:09 +04:00
|
|
|
AC_RUN_IFELSE([AC_LANG_PROGRAM([$2], [$3])],
|
2006-02-05 04:28:05 +03:00
|
|
|
[AS_VAR_SET(lang_var, ["yes"])],
|
|
|
|
|
[AS_VAR_SET(lang_var, ["no"])],
|
|
|
|
|
[AS_VAR_SET(lang_var, ["cross compiling"])])
|
|
|
|
|
AC_LANG_POP($1)])
|
|
|
|
|
AS_IF([test "AS_VAR_GET(lang_var)" = "no"],
|
|
|
|
|
[cat <<EOF >&2
|
|
|
|
|
**********************************************************************
|
|
|
|
|
* It appears that your $1 compiler is unable to produce working
|
|
|
|
|
* executables. A simple test application failed to properly
|
|
|
|
|
* execute. Note that this is likely not a problem with Open MPI,
|
|
|
|
|
* but a problem with the local compiler installation. More
|
|
|
|
|
* information (including exactly what command was given to the
|
|
|
|
|
* compiler and what error resulted when the command was executed) is
|
|
|
|
|
* available in the config.log file in this directory.
|
|
|
|
|
**********************************************************************
|
|
|
|
|
EOF
|
Another project that has been brewing for a week or so...
We have repeatedly seen users inadvertantly try to use a C compiler
for $CXX (e.g., using icc instead of icpc in recent versions of the
Intel compiler). Unfortunately, this would "sorta work", meaning that
configure would complete successfully and the build would fail much
later in the process (when $CXX was used to try to link a C++
compiler). This was further compounded by the fact that many C
compilers will switch into "C++ mode" when they compile files that end
in .cc -- meaning that they'll *compile* C++ codes properly, but they
won't *link* properly. Hence, users would get all the way down to
compiling the C++ MPI bindings or ompi_info (i.e., very late in the
build process) before the problem became evident.
We already have a test in configure that tries to compile, link, and
run a sample C++ program. This helped ensure that $CXX was a valid
compiler, but it did not catch if the user accidentally supplied a C
compiler instead of a C++ compiler because the test program was simply
"return 0". This commit updates the test program to use some
C++-specific constructs (std::string) so that if the user supplies a C
compiler in $CXX, the program may *compile*, but it will definitely
fail to *link*.
Hence, the process will fail early in configure (with a descriptive
message about how the compiler failed to work properly) rather than
late in the build.
This commit was SVN r10829.
2006-07-15 14:27:09 +04:00
|
|
|
$5], [$4])
|
2006-02-05 04:28:05 +03:00
|
|
|
|
|
|
|
|
AS_VAR_POPDEF([lang_var])dnl
|
|
|
|
|
])
|