Jeff Hammond <[email protected]> writes:
One corresponds to an MPICH configure with my default environment and the other with a vanilla environment not including my GCC 4.8.1 install. When the environment knows about GCC 4.8.1, configure tests related to C++ fail.
See the icc(1) man page: GNU* gcc Interoperability C++ compilers are interoperable if they can link object files and libraries generated by one compiler with object files and libraries generated by the second compiler, and the resulting executable runs successfully. Some GNU* gcc versions are not interoperable, some versions are interoperable. By default, the Intel compiler will generate code that is interoperable with the version of gcc it finds on your system. The Intel(R) C++ Compiler options that affect GNU* gcc interoperability include: · -cxxlib · -gcc-name · -gcc-version · -gxx-name · -fabi-version · -no-gcc (see gcc Predefined Macros for more information) The Intel(R) C++ Compiler is interoperable with GNU* gcc compiler versions greater than or equal to 3.2. See the Intel(R) C++ Compiler Documentation for more information. We just debugged essentially this problem from some BW users that couldn't manage to have exactly the same GCC modules loaded when they configured PETSc as when they ran later (it took way too many emails to pin them down on this bit of the environment changing). The gcc-version also affects the dialect and attributes, so for example, when icc finds a recent version of gcc, __attribute((deprecated("explanation why"))) works, but if it finds an old version of gcc, then "explanation why" is not understood, so only __attribute((deprecated)) can be used. This dependence on whatever gcc is found in the path is horrendous for reproducibility since it makes it harder to create configurations that don't depend on the environment and even if you concede dependence on the environment, few people realize that the Intel's compilers change behavior based on the version of gcc found in PATH.