So how would I do that? Does LIBS=<string> accept spaces in the string? Something like this perhaps:
LIBS="-L/cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin -lifcore" But I'm starting to believe that my intel install is somehow broken. I'm getting these intel compilers from rpm's provided by our cluster vendor. On a workstation I can try yum remove and install of the intel packages. Not so easy on a production cluster. Is this worth a try? Or will it just copy/paste the same broken (?) stuff in the same place? Chris dr. ir. Christiaan Klaij | CFD Researcher | Research & Development MARIN | T +31 317 49 33 44 | [email protected]<mailto:[email protected]> | www.marin.nl<http://www.marin.nl> [LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia> [Twitter] <https://twitter.com/MARIN_nieuws> [Facebook] <https://www.facebook.com/marin.wageningen> MARIN news: Comparison of uRANS and BEM-BEM for propeller pressure pulse prediction<http://www.marin.nl/web/News/News-items/Comparison-of-uRANS-and-BEMBEM-for-propeller-pressure-pulse-prediction.htm> ________________________________ From: Matthew Knepley <[email protected]> Sent: Wednesday, January 04, 2017 3:13 PM To: Klaij, Christiaan Cc: petsc-users; Satish Balay Subject: Re: [petsc-users] problems after glibc upgrade to 2.17-157 On Wed, Jan 4, 2017 at 7:37 AM, Klaij, Christiaan <[email protected]<mailto:[email protected]>> wrote: I've tried with: --LIBS=/cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libifcore.a -lstdc++\\ This is likely connected to the problem below, but I would have to see the log. but that doesn't seem to make a difference. With the option --with-cxx=0 the configure part does work(!), but then I get **************************ERROR************************************* Error during compile, check Linux-x86_64-Intel/lib/petsc/conf/make.log Send it and Linux-x86_64-Intel/lib/petsc/conf/configure.log to [email protected]<mailto:[email protected]> ******************************************************************* Here is the problem: CLINKER /projects/developers/cklaij/ReFRESCO/Dev/trunk/Libs/build/petsc-3.7.4/Linux-x86_64-Intel/lib/libpetsc.so.3.7.4 ld: /cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libifcore.a(for_init.o): relocation R_X86_64_32 against `.rodata.str1.4' can not be used when making a shared object; recompile with -fPIC /cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libifcore.a: could not read symbols: Bad value Clearly there is something wrong with the compiler install. However, can you put a libifcore.so in LIBS instead? Matt See the attached log files. Chris dr. ir. Christiaan Klaij | CFD Researcher | Research & Development MARIN | T +31 317 49 33 44<tel:+31%20317%20493%20344> | [email protected]<mailto:[email protected]> | www.marin.nl<http://www.marin.nl> [LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia> [Twitter] <https://twitter.com/MARIN_nieuws> [Facebook] <https://www.facebook.com/marin.wageningen> MARIN news: MARIN Report 119: highlighting naval research projects<http://www.marin.nl/web/News/News-items/MARIN-Report-119-highlighting-naval-research-projects.htm> ________________________________ From: Matthew Knepley <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 04, 2017 1:43 PM To: Klaij, Christiaan Cc: petsc-users; Satish Balay Subject: Re: [petsc-users] problems after glibc upgrade to 2.17-157 On Wed, Jan 4, 2017 at 4:32 AM, Klaij, Christiaan <[email protected]<mailto:[email protected]>> wrote: Satish, I tried your suggestion: --with-clib-autodetect=0 --with-fortranlib-autodetect=0 --with-cxxlib-autodetect=0 LIBS=LIBS=/path_to/libifcore.a I guess I don't really need "LIBS= " twice (?) so I've used this line: LIBS=/cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libifcore.a Unfortunately, this approach also fails (attached log): Ah, this error is much easier: Executing: mpif90 -o /tmp/petsc-3GfeyZ/config.compilers/conftest -fPIC -g -O3 /tmp/petsc-3GfeyZ/config.compilers/conftest.o /tmp/petsc-3GfeyZ/config.compilers/cxxobj.o /tmp/petsc-3GfeyZ/config.compilers/confc.o -ldl /cm/shared/apps/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libifcore.a Possible ERROR while running linker: exit code 256 stderr: /tmp/petsc-3GfeyZ/config.compilers/cxxobj.o:(.gnu.linkonce.d.DW.ref.__gxx_personality_v0+0x0): undefined reference to `__gxx_personality_v0' Intel as lazy writing its C++ compiler, so it uses some of g++. If you want to use C++, you will need to add -lstdc++ to your LIBS variable (I think). Otherwise, please turn it off using --with-cxx=0. Thanks, Matt ******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- Fortran could not successfully link C++ objects ******************************************************************************* There are multiple libifcore.a in the intel compiler lib: one in intel64_lin and one in intel64_lin_mic. Tried both, got same error. Chris dr. ir. Christiaan Klaij | CFD Researcher | Research & Development MARIN | T +31 317 49 33 44<tel:%2B31%20317%2049%2033%2044> | mailto:[email protected]<mailto:[email protected]> | http://www.marin.nl MARIN news: http://www.marin.nl/web/News/News-items/Comparison-of-uRANS-and-BEMBEM-for-propeller-pressure-pulse-prediction.htm ________________________________________ From: Satish Balay <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 03, 2017 4:37 PM To: Klaij, Christiaan Cc: [email protected]<mailto:[email protected]> Subject: Re: [petsc-users] problems after glibc upgrade to 2.17-157 Do you have similar issues with gnu compilers? It must be some incompatibility with intel compilers with this glibc change. >>>>>>>>> compilers: Check that C libraries can be used from Fortran Pushing language FC Popping language FC Pushing language FC Popping language FC Pushing language FC Popping language FC **** Configure header /tmp/petsc-rOjdnN/confdefs.h **** <<<<<<<<<< Thre is a bug in configure [Matt?] that eats away some of the log - so I don't see the exact error you are getting. If standalone micc/mpif90 etc work - then you can try the following additional options: --with-clib-autodetect=0 --with-fortranlib-autodetect=0 --with-cxxlib-autodetect=0 LIBS=LIBS=/path_to/libifcore.a [replace "path_to" with the correct path to the ifort lubifcore.a library] Note: I have a RHEL7 box with this glibc - and I don't see this issue. >>>> -bash-4.2$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) -bash-4.2$ rpm -q glibc glibc-2.17-157.el7_3.1.x86_64 glibc-2.17-157.el7_3.1.i686 -bash-4.2$ mpiicc --version icc (ICC) 17.0.0 20160721 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. -bash-4.2$ <<<< Satish On Tue, 3 Jan 2017, Klaij, Christiaan wrote: > > I've been using petsc-3.7.4 with intel mpi and compilers, > superlu_dist, metis and parmetis on a cluster running > SL7. Everything was working fine until SL7 got an update where > glibc was upgraded from 2.17-106 to 2.17-157. > > This update seemed to have broken (at least) parmetis: the > standalone binary gpmetis started to give a segmentation > fault. The core dump shows this: > > Core was generated by `gpmetis'. > Program terminated with signal 11, Segmentation fault. > #0 0x00002aaaac6b865e in memmove () from /lib64/libc.so.6 > > That's when I decided to recompile, but to my surprise I cannot > even get past the configure stage (log attached)! > > ******************************************************************************* > UNABLE to EXECUTE BINARIES for ./configure > ------------------------------------------------------------------------------- > Cannot run executables created with FC. If this machine uses a batch system > to submit jobs you will need to configure using ./configure with the > additional option --with-batch. > Otherwise there is problem with the compilers. Can you compile and run code > with your compiler 'mpif90'? > See http://www.mcs.anl.gov/petsc/documentation/faq.html#libimf > ******************************************************************************* > > Note the following: > > 1) Configure was done with the exact same options that worked > fine before the update of SL7. > > 2) The intel mpi and compilers are exactly the same as before the > update of SL7. > > 3) The cluster does not require a batch system to run code. > > 4) I can compile and run code with mpif90 on this cluster. > > 5) The problem also occurs on a workstation running SL7. > > Any clues on how to proceed? > Chris > > > dr. ir. Christiaan Klaij | CFD Researcher | Research & Development > MARIN | T +31 317 49 33 44<tel:%2B31%20317%2049%2033%2044> | > mailto:[email protected]<mailto:[email protected]> | http://www.marin.nl > > MARIN news: > http://www.marin.nl/web/News/News-items/Comparison-of-uRANS-and-BEMBEM-for-propeller-pressure-pulse-prediction.htm > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
