I think the guilty parties are CPATH and possibly LD_LIBRARY_PATH will also
cause problems.
You can try having def formGNUConfigureArgs(self): in sowing.py remove those
two environmental variables and then I bet the build will go through with the
ancient gcc
Now it is probably safe to just permanently have sowing.py remove these two
variables but there could always be unpredictable corner cases where removing
them does harm. One approach would be to try sowing configure first and if that
fails try again without the CPATH but we don't have simple logic for retrying
package configures in the package system so I am guessing this would be messy.
Other messy solutions exist like trying the gnu compilers inside sowing.py with
and without the CPATH but that really isn't our business, it is more sowing's
configure business. Another solution that would work in your case is to have
sowing.py unload the intel module before calling the sowing configure. I think
the correct long term answer is to have sowing deal with the problem since
there is no perfect way for PETSc configure to cleanup before calling sowing.
As Satish said the basic problem is that loading the Intel tools breaks the
GNU classic compilers and unbreaking them is possible but fragile.
Barry
LD_LIBRARY_PATH=/share/apps/intel-2020.2/compilers_and_libraries/linux/mpi/intel64/lib/release:/share/apps/intel-2020.2/compilers_and_libraries/linux/mpi/intel64/lib:/share/apps/intel-2020.2/compilers_and_libraries/linux/mpi/intel64/libfabric/lib:/share/apps/intel-2020.2/debugger_2020/libipt/intel64/lib:/share/apps/intel-2020.2/debugger_2020/python/intel64/lib:/share/apps/intel-2020.2/compilers_and_libraries/linux/tbb/lib/intel64/gcc4.8:/share/apps/intel-2020.2/compilers_and_libraries/linux/daal/lib/intel64:/share/apps/intel-2020.2/compilers_and_libraries/linux/mkl/lib/intel64:/share/apps/intel-2020.2/compilers_and_libraries/linux/ipp/lib/intel64:/share/apps/intel-2020.2/compilers_and_libraries/linux/lib/intel64
INTEL_HOME=/share/apps/intel-2020.2/compilers_and_libraries/linux
PSTLROOT=/share/apps/intel-2020.2/compilers_and_libraries/linux/pstl
FI_PROVIDER_PATH=/share/apps/intel-2020.2/compilers_and_libraries/linux/mpi/intel64/libfabric/lib/prov
SSH_AUTH_SOCK=/tmp/ssh-5jDvL6G8Wz/agent.131848
_ModuleTable004_=ZmlsZXMvYmFzZTovc2hhcmUvYXBwcy9tb2R1bGVmaWxlcy9MaW51eDovc2hhcmUvYXBwcy9tb2R1bGVmaWxlcy9Db3JlOi91c3Ivc2hhcmUvbG1vZC9sbW9kL21vZHVsZWZpbGVzL0NvcmUiLH0=
CPATH=/share/apps/intel-2020.2/compilers_and_libraries/linux/tbb/include:/share/apps/intel-2020.2/compilers_and_libraries/linux/daal/include:/share/apps/intel-2020.2/compilers_and_libraries/linux/pstl/stdlib:/share/apps/intel-2020.2/compilers_and_libraries/linux/mkl/include:/share/apps/intel-2020.2/compilers_and_libraries/linux/ipp/include:/share/apps/intel-2020.2/compilers_and_libraries/linux/include
__LMOD_REF_COUNT__LMFILES_=/share/apps/modulefiles/base/gmake/4.3.lua:1;/share/apps/modulefiles/base/intel/2020.2.lua:1;/share/apps/modulefiles/intel2020.2/impi/2020.2.lua:1;/share/apps/modulefiles/intel2020.2/petsc/master-g.lua:1
> On Dec 3, 2020, at 10:32 AM, Satish Balay via petsc-dev
> <petsc-dev@mcs.anl.gov> wrote:
>
>>>>>>>
> configure:6247: /lib/cpp conftest.c
> In file included from conftest.c:11:0:
> /share/apps/intel-2020.2/compilers_and_libraries/linux/include/limits.h:37:54:
> error: missing binary operator before token "("
> defined(__has_include_next) && __has_include_next(<limits.h>)
> ^
> configure:6247: $? = 1
> <<<<<
>
>
> I've seen these bad interactions with intel compilers and gcc. i.e - when
> intel compiler modifies env for itself - it breaks gcc.
>
> [and this newer version if intel compiler requires a newer gcc in PATH anyway
> :( - otherwise some c++ features don't work..]
>
> Don't know how to deal with such issues [created by intel compilers..]
>
> Satish
>
> On Thu, 3 Dec 2020, Blaise A Bourdin wrote:
>
>>
>>
>>> On Dec 3, 2020, at 10:15 AM, Satish Balay <ba...@mcs.anl.gov> wrote:
>>>
>>> On Thu, 3 Dec 2020, Blaise A Bourdin wrote:
>>>
>>>> Hi,
>>>>
>>>> Building sowing fails when I try to compile petsc on a RHEL7 system with
>>>> the default gcc (4.8.5) and intel compilers.
>>>> Looking at the log file and sowing.py, it looks like sowing configure step
>>>> does not inherit from the compilers detected by BuildSystem at an earlier
>>>> stage, so that instead of using the intel compilers, it pulls my ancient
>>>> gcc.
>>>>
>>>> Instead of having to clumsily add --download-sowing-cc=mpicc
>>>> --download-sowing-cxx=mpicxx to the configure options, would it make sense
>>>> to populate the CC, CXX, CPP, CXXPP configure options (sowing.py:40-47)
>>>> with the PETSc compilers? I can do it if that is OK.
>>>
>>> The reason for the current design is - sowing [and similar build tools] -
>>> are for the build machine - and the petsc library [and CC etc] are for the
>>> compute machine [in cases where these are different].
>>>
>>> Also sowing didn't work with most compilers - and default gcc [from PATH]
>>> was the most sane default compiler for it.
>>>
>>> And defaults don't always work [if defaults are changed - if might fix this
>>> senario - but break in others that are curently working...] - hence we have
>>> these extra options for use - in these cases.
>>
>> OK, that does make a lot of sense.
>>
>>>
>>> I'm surprised sowing doesn't work with gcc-4.8.5. I'll have to recheck.
>> I am attaching my sowing config.log and configure.log
>>
>>
>>
>> Regards,
>> Blaise
>>
>> --
>> A.K. & Shirley Barton Professor of Mathematics
>> Adjunct Professor of Mechanical Engineering
>> Adjunct of the Center for Computation & Technology
>> Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA
>> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 Web
>> http://www.math.lsu.edu/~bourdin
>>
>>
>
