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

[Jed Brown]

Jeff Hammond <jeff.science at gmail.com> writes:

> So there is no way to disable Intel's auto-detection of GCC from PATH?

Well, you can turn off gcc compatibility using -no-gcc, but they still
find and execute the gcc found in PATH:

$ strace -f icc -E -no-gcc dummy.c |& grep execve
execve("/soft/com/packages/intel/13/update4/bin/icc", ["icc", "-E", "-no-gcc", "dummy.c"], [/* 39 vars */]) = 0
[pid 10519] execve("/usr/lib/lightdm/lightdm/gcc", ["gcc", "--print-libgcc-file-name", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
[pid 10519] execve("/usr/sbin/gcc", ["gcc", "--print-libgcc-file-name", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
[pid 10519] execve("/usr/bin/gcc", ["gcc", "--print-libgcc-file-name", "-m64"], [/* 40 vars */]) = 0
[pid 10520] execve("/usr/lib/lightdm/lightdm/gcc", ["gcc", "--print-search-dirs", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
[pid 10520] execve("/usr/sbin/gcc", ["gcc", "--print-search-dirs", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
[pid 10520] execve("/usr/bin/gcc", ["gcc", "--print-search-dirs", "-m64"], [/* 40 vars */]) = 0
[pid 10521] execve("/usr/lib/lightdm/lightdm/gcc", ["gcc", "-m64", "-v", "-E", "/tmp/iccLOE84g.c"], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
[pid 10521] execve("/usr/sbin/gcc", ["gcc", "-m64", "-v", "-E", "/tmp/iccLOE84g.c"], [/* 40 vars */]) = -1 ENOENT (No such file or directory)
[pid 10521] execve("/usr/bin/gcc", ["gcc", "-m64", "-v", "-E", "/tmp/iccLOE84g.c"], [/* 40 vars */]) = 0
[pid 10522] execve("/usr/lib/gcc/x86_64-linux-gnu/4.4.7/cc1", ["/usr/lib/gcc/x86_64-linux-gnu/4."..., "-E", "-quiet", "-v", "-imultilib", ".", "-imultiarch", "x86_64-linux-gnu", "/tmp/iccLOE84g.c", "-D_FORTIFY_SOURCE=2", "-m64", "-mtune=generic", "-fstack-protector"], [/* 42 vars */]) = 0
[pid 10523] execve("/nfs/software/linux-ubuntu_precise_amd64/com/packages/intel/13/update4/composer_xe_2013.3.163/bin/intel64/mcpcom", ["/nfs/software/linux-ubuntu_preci"..., "@/tmp/iccargQXA8hT"], [/* 40 vars */] <unfinished ...>
[pid 10523] <... execve resumed> )      = 0

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

Evidently -gcc-version is deprecated, though the man page does not
mention that.  You can use -gcc-name=/path/to/gcc-4.8.1.

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

$ cat dummy.c
__GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__
$ icc -E -gcc-version=480 dummy.c
icc: command line remark #10010: option '-gcc-version=480' is deprecated and will be removed in a future release. See '-help deprecated'
icc: warning #10126: invalid value '480' for '-gcc-version'; assuming '470'
# 1 "dummy.c"
4 7 0

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

No, but many people configure software and then expect 'git pull &&
make' to work correctly.  Now they have to remember to load the correct
gcc module to coerce the Intel compiler to behave the same way it did
during configure (or explicitly pass -gcc-name=/path/to/selected/gcc).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130705/6b70e629/attachment.sig>