Re: [petsc-dev] Building Sowing fails with old system gcc
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 > 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() > ^ > 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 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].
Re: [petsc-dev] Building Sowing fails with old system gcc
> On Dec 3, 2020, at 10:32 AM, Satish Balay 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() > ^ > 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..] Let’s not try to fix what the intel compilers break! Passing epic and mlicxx as the compilers to sowing works well enough. Regards, Blaise > > Satish > > On Thu, 3 Dec 2020, Blaise A Bourdin wrote: > >> >> >>> On Dec 3, 2020, at 10:15 AM, Satish Balay 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 >> >> > -- 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
Re: [petsc-dev] Building Sowing fails with old system gcc
>> 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() ^ 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 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 > >
Re: [petsc-dev] Building Sowing fails with old system gcc
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. I'm surprised sowing doesn't work with gcc-4.8.5. I'll have to recheck. Satish
[petsc-dev] Building Sowing fails with old system gcc
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. 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