[mpich-discuss] why does a non-standard GCC in PATH break my all-Intel MPICH config?

[Jeff Hammond]

>> 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)

So there is no way to disable Intel's auto-detection of GCC from PATH?
 I do not see the options
http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/copts/ccpp_options/option_no-gcc.htm
or http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/copts/ccpp_options/option_gcc-version.htmhaving
any effect in this regard.

>        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.

Well that's complete nonsense since it is clearly not compatible with GCC 4.8.1.

> 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,

You mean this is a _runtime_ dependency?  Thank goodness I am not
trained in martial arts, or I would have just killed myself with a
lethal slap to the forehead.

>   __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.

I completely agree.  This is atrocious behavior.  Does the Intel C++
compiler not work if I don't have GCC installed?  What if - as is my
inalienable right as the operator of my computer - I alias all GCC
commands to /usr/bin/light-machine-room-on-fire or
/usr/bin/pull-the-plug-on-grandma?  I suppose the Intel commercial
license has an indemnification clause, because otherwise, I could get
rich by exploiting this nonsense.

Jeff


-- 
Jeff Hammond
jeff.science at gmail.com