1
1
Граф коммитов

2 Коммитов

Автор SHA1 Сообщение Дата
Jeff Squyres
4eb3ee7835 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 10:27:09 +00:00
Brian Barrett
d751d3bacf * Try to execute a simple application with a compiler (in non-cross-compile
situations) before going on to tests that run executables with the
  compiler.  Print a friendly error message if it fails.  Hopefully, this
  will help people with borked compilers.

This commit was SVN r8898.
2006-02-05 01:28:05 +00:00