Re: PIC flags not found for mpif77(ifort)
* Christian Rössel wrote on Fri, Dec 17, 2010 at 01:25:45PM CET: On 12/16/2010 09:54 PM, Ralf Wildenhues wrote: And now I wonder why you are having problems with 'mpif77 -f77=ifort' because either it claims to be GNU (and then should accept -fPIC) or it doesn't claim to be GNU (and then my proposed patch, including the fix you spotted to double-quote the [CF]) should have worked. Can you show the config.log for the F77=mpif77 case that fails to detect the PIC flag? Thanks. I checked again and you are right, with the fixed patch it works out of the box. ifort 11.1 does not claim to be a GNU compiler (whereas icc and icpc do). I somehow mixed up the output of the different compilers as we use them all in our project. Sorry for the confusion. Ah, cool. I'm pushing the other patch then too. The setting of $archive_cmds still needs fixes for both Intel and PGI compilers too, and I think we should strive to remove duplicate entries for compilers: I'll post a followup cleanup patch. Thanks, Ralf
Re: PIC flags not found for mpif77(ifort)
Hi Ralf, On 12/16/2010 09:54 PM, Ralf Wildenhues wrote: Hello Christian, * Christian Rössel wrote on Thu, Dec 16, 2010 at 05:27:23PM CET: Am 12/16/2010 11:19 AM, schrieb Christian Rössel: Am 12/15/2010 9:21 PM, schrieb Ralf Wildenhues: Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? yes, the Intel compiler claims to be a GNU compiler: checking for gcc... icc [...] checking whether we are using the GNU C compiler... yes I'm not sure how autoconf performs this check, but we came up with the following to distinguish Intel from GNU: Thanks. So far we've more or less fared well with the assumption that if the compiler claims it is GNU, then we just use the GCC settings. If that doesn't work, then it's the compiler's fault to claim being GNU. And now I wonder why you are having problems with 'mpif77 -f77=ifort' because either it claims to be GNU (and then should accept -fPIC) or it doesn't claim to be GNU (and then my proposed patch, including the fix you spotted to double-quote the [CF]) should have worked. Can you show the config.log for the F77=mpif77 case that fails to detect the PIC flag? Thanks. I checked again and you are right, with the fixed patch it works out of the box. ifort 11.1 does not claim to be a GNU compiler (whereas icc and icpc do). I somehow mixed up the output of the different compilers as we use them all in our project. Sorry for the confusion. As far as I remember, the older ifort versions at least didn't claim to be GNU (unlike icc or icpc). #if defined(__GNUC__) ! (defined(__INTEL_COMPILER) || defined(__ICC)) /* using a gnu but not an intel compiler */ #endif to prevent configure to identify Intel compilers as GNU compiler you need to add following code to _AC_LANG_COMPILER_GNU: #if defined(__INTEL_COMPILER) || defined(__ICC) choke me #endif This is not a valid patch, I know. Can you please give me a hint where to find a how-to for providing autotools patches? Good question. The git[0] development trees[1] of Autoconf and Libtool have files named HACKING that explain some bits. Generalities are documented in the GNU Coding Standards[2]. Portability issues are documented in the portability sections of the Autoconf manual[3]. Patches posted as 'diff -u' output are fine however; 'git diff' or 'git format-patch' output is more convenient for us. [0] http://git-scm.com/ [1] http://savannah.gnu.org/git/?group=autoconf http://savannah.gnu.org/git/?group=libtool [2] http://www.gnu.org/prep/standards/html_node/index.html [3] http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html Thanks a lot! Christian BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). The patch for PGI works! Great. I've pushed that patch to the git tree. Thanks, Ralf -- Christian Rössel Jülich Supercomputing Centre Telefon +49 2461 61-1773 Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: PIC flags not found for mpif77(ifort)
Hi Ralf, Am 12/15/2010 9:21 PM, schrieb Ralf Wildenhues: * Christian Rössel wrote on Wed, Dec 15, 2010 at 04:38:13PM CET: Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Alternatively, the untested patch below should help as well. Can you try it out? Unfortunately the patch didn't work. configure does not execute the new case branch although the innermost condition matches. Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? yes, the Intel compiler claims to be a GNU compiler: checking for gcc... icc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes I'm not sure how autoconf performs this check, but we came up with the following to distinguish Intel from GNU: #if defined(__GNUC__) ! (defined(__INTEL_COMPILER) || defined(__ICC)) /* using a gnu but not an intel compiler */ #endif BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). The patch for PGI works! Thanks a lot, Christian Thanks, Ralf diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index e735c75..7323986 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4343,6 +4343,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' ;; + *Portland\ Group*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + ;; esac ;; esac
Re: PIC flags not found for mpif77(ifort)
Hi Ralf, Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Hello Christian, * Christian Rössel wrote on Fri, Dec 10, 2010 at 02:56:51PM CET: ./configure --enable-shared F77=mpif77 ... where mpif77 translates to ifort -I/opt/parastation/mpi2-intel/include -L/opt/parastation/mpi2-intel/lib -Wl,-rpath -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64 -Wl,--enable-new-dtags -lpscom -lrt configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC flags are discovered though): configure:17627: checking for mpif77 option to produce PIC configure:17899: result: There is no more output concerning the PIC flags in config.log. With F77=ifort everything works as expected: configure:16805: checking for ifort option to produce PIC configure:17077: result: -fPIC Yeah, that's because libtool.m4 macros partly match by name, unless the compiler claims to be GCC. A bit dumb, sure, but it's not easy to avoid because portable testing of these flags is not trivial. We might have to think about a more general way to extract the compiler name from an MPI driver (-show and -showme come to mind). For the moment you should be able to work around it using configure lt_cv_prog_compiler_pic_F77=-fPIC \ lt_cv_prog_compiler_pic_FC=-fPIC \ but I'm not sure if you also need fixes for missing -static and -Wl, flags (lt_prog_compiler_wl_F77 and lt_prog_compiler_static_F77 ...). This requires Libtool = 2.4. Alternatively, the untested patch below should help as well. Can you try it out? the patch works if you double quote CF and patch _AC_LANG_COMPILER_GNU (see other mail): diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 1f61140..e735c75 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ;; +*Intel*\ [[CF]]*Compiler*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' + ;; esac ;; esac Thanks, Christian Thanks for the report, Ralf Fix PIC flags with mpif77 using ifort on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: Match Intel compiler also using $CC -V output, to avoid false negatives with compiler drivers like mpif77. Report by Christian Rössel. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 1f61140..e735c75 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ;; +*Intel*\ [CF]*Compiler*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' + ;; esac ;; esac -- Christian Rössel Jülich Supercomputing Centre Telefon +49 2461 61-1773 Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: PIC flags not found for mpif77(ifort)
Hi Ralf, Am 12/16/2010 11:19 AM, schrieb Christian Rössel: Hi Ralf, Am 12/15/2010 9:21 PM, schrieb Ralf Wildenhues: * Christian Rössel wrote on Wed, Dec 15, 2010 at 04:38:13PM CET: Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Alternatively, the untested patch below should help as well. Can you try it out? Unfortunately the patch didn't work. configure does not execute the new case branch although the innermost condition matches. Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? yes, the Intel compiler claims to be a GNU compiler: checking for gcc... icc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes I'm not sure how autoconf performs this check, but we came up with the following to distinguish Intel from GNU: #if defined(__GNUC__) ! (defined(__INTEL_COMPILER) || defined(__ICC)) /* using a gnu but not an intel compiler */ #endif to prevent configure to identify Intel compilers as GNU compiler you need to add following code to _AC_LANG_COMPILER_GNU: #if defined(__INTEL_COMPILER) || defined(__ICC) choke me #endif This is not a valid patch, I know. Can you please give me a hint where to find a how-to for providing autotools patches? Thanks, Christian BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). The patch for PGI works! Thanks a lot, Christian Thanks, Ralf diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index e735c75..7323986 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4343,6 +4343,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' ;; +*Portland\ Group*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + ;; esac ;; esac
Re: PIC flags not found for mpif77(ifort)
Hello Christian, * Christian Rössel wrote on Thu, Dec 16, 2010 at 05:27:23PM CET: Am 12/16/2010 11:19 AM, schrieb Christian Rössel: Am 12/15/2010 9:21 PM, schrieb Ralf Wildenhues: Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? yes, the Intel compiler claims to be a GNU compiler: checking for gcc... icc [...] checking whether we are using the GNU C compiler... yes I'm not sure how autoconf performs this check, but we came up with the following to distinguish Intel from GNU: Thanks. So far we've more or less fared well with the assumption that if the compiler claims it is GNU, then we just use the GCC settings. If that doesn't work, then it's the compiler's fault to claim being GNU. And now I wonder why you are having problems with 'mpif77 -f77=ifort' because either it claims to be GNU (and then should accept -fPIC) or it doesn't claim to be GNU (and then my proposed patch, including the fix you spotted to double-quote the [CF]) should have worked. Can you show the config.log for the F77=mpif77 case that fails to detect the PIC flag? Thanks. As far as I remember, the older ifort versions at least didn't claim to be GNU (unlike icc or icpc). #if defined(__GNUC__) ! (defined(__INTEL_COMPILER) || defined(__ICC)) /* using a gnu but not an intel compiler */ #endif to prevent configure to identify Intel compilers as GNU compiler you need to add following code to _AC_LANG_COMPILER_GNU: #if defined(__INTEL_COMPILER) || defined(__ICC) choke me #endif This is not a valid patch, I know. Can you please give me a hint where to find a how-to for providing autotools patches? Good question. The git[0] development trees[1] of Autoconf and Libtool have files named HACKING that explain some bits. Generalities are documented in the GNU Coding Standards[2]. Portability issues are documented in the portability sections of the Autoconf manual[3]. Patches posted as 'diff -u' output are fine however; 'git diff' or 'git format-patch' output is more convenient for us. [0] http://git-scm.com/ [1] http://savannah.gnu.org/git/?group=autoconf http://savannah.gnu.org/git/?group=libtool [2] http://www.gnu.org/prep/standards/html_node/index.html [3] http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). The patch for PGI works! Great. I've pushed that patch to the git tree. Thanks, Ralf
Re: PIC flags not found for mpif77(ifort)
Hi Ralf, Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Hello Christian, * Christian Rössel wrote on Fri, Dec 10, 2010 at 02:56:51PM CET: ./configure --enable-shared F77=mpif77 ... where mpif77 translates to ifort -I/opt/parastation/mpi2-intel/include -L/opt/parastation/mpi2-intel/lib -Wl,-rpath -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64 -Wl,--enable-new-dtags -lpscom -lrt configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC flags are discovered though): configure:17627: checking for mpif77 option to produce PIC configure:17899: result: There is no more output concerning the PIC flags in config.log. With F77=ifort everything works as expected: configure:16805: checking for ifort option to produce PIC configure:17077: result: -fPIC Yeah, that's because libtool.m4 macros partly match by name, unless the compiler claims to be GCC. A bit dumb, sure, but it's not easy to avoid because portable testing of these flags is not trivial. We might have to think about a more general way to extract the compiler name from an MPI driver (-show and -showme come to mind). For the moment you should be able to work around it using configure lt_cv_prog_compiler_pic_F77=-fPIC \ lt_cv_prog_compiler_pic_FC=-fPIC \ but I'm not sure if you also need fixes for missing -static and -Wl, flags (lt_prog_compiler_wl_F77 and lt_prog_compiler_static_F77 ...). This requires Libtool = 2.4. I upgraded to 2.4. but this leads to another error. I will investigate this. Alternatively, the untested patch below should help as well. Can you try it out? Unfortunately the patch didn't work. configure does not execute the new case branch although the innermost condition matches. BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. Thanks, Christian Thanks for the report, Ralf Fix PIC flags with mpif77 using ifort on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: Match Intel compiler also using $CC -V output, to avoid false negatives with compiler drivers like mpif77. Report by Christian Rössel. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 1f61140..e735c75 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ;; +*Intel*\ [CF]*Compiler*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' + ;; esac ;; esac
Re: PIC flags not found for mpif77(ifort)
* Christian Rössel wrote on Wed, Dec 15, 2010 at 04:38:13PM CET: Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Alternatively, the untested patch below should help as well. Can you try it out? Unfortunately the patch didn't work. configure does not execute the new case branch although the innermost condition matches. Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). Thanks, Ralf diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index e735c75..7323986 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4343,6 +4343,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' ;; + *Portland\ Group*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + ;; esac ;; esac
