[petsc-dev] Building Sowing fails with old system gcc

[Barry Smith]

  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 at 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 <balay at 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
>> 
>> 
>