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)
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)
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
Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux
Wrong list in the first place, sorry.
Christian
Original Message
Subject: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux
Date: Tue, 18 Sep 2012 18:38:20 -0700
From: Christian Rössel
To: libtool
CC: t...@subnetz.org
Dear all,
please find attached a patch that fixes the erroneous detection of PIC
flags in case when CXX is a MPI wrapper that uses pgCC or pgcpp on
GNU/Linux as well as the wrong rpath option.
The testsuite.log output was created by configuring with CC=pgcc
CXX=pgCC F77=pgf77 FC=pgf90 and running make check. Is this the supposed
way to do it? Compiler version is 10.1-0.
There were two unexpected failures, in the patched as well as in the
unpatched version:
110: C++ exception handling FAILED
(exceptions.at:385)
121: Run tests with low max_cmd_len FAILED
(cmdline_wrap.at:43)
BTW, is there a recommendation whether or not to use tabs for
indentation in libtool.m4?
Thanks,
Christian
--
Dipl-Phys.
Christian Rössel
Forschungszentrum Jülich GmbH
Jülich Supercomputing Centre
Telefon: +1 541 346 2484
E-Mail: c.roes...@fz-juelich.de
Internet: http://www.fz-juelich.de/jsc
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
diff --git a/gnulib b/gnulib
index c3d1ccf..0cd711b 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit c3d1ccfdb375b4cb1b912116c084a61422ef47e3
+Subproject commit 0cd711b27ba11019c96314a42e197bc288f415d7-dirty
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4413a6d..ee63dda 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4055,13 +4055,19 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_static, $1)='-qstaticlink'
;;
*)
- case `$CC -V 2>&1 | sed 5q` in
+ case `$CC -V 2>&1` in
*Sun\ C*)
# Sun C++ 5.9
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
;;
+*Portland\ Group*)
+ # Portland Group C++ compiler
+ _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
@@ -4375,7 +4381,7 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_static, $1)='-qstaticlink'
;;
*)
- case `$CC -V 2>&1 | sed 5q` in
+ case `$CC -V 2>&1` in
*Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 8.[[0-3]]*)
# Sun Fortran 8.3 passes all unrecognized flags to the linker
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
@@ -4797,6 +4803,10 @@ _LT_EOF
_LT_TAGVAR(whole_archive_flag_spec, $1)='$wl--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; func_echo_all \"$new_convenience\"` $wl--no-whole-archive'
tmp_addflag=' $pic_flag'
;;
+ pgCC* | pgcpp*) # Portland Group C++ compiler
+ _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; func_echo_all \"$new_convenience\"` ${wl}--no-whole-archive'
+ tmp_addflag=' $pic_flag'
+ ;;
pgf77* | pgf90* | pgf95* | pgfortran*)
# Portland Group f77 and f90 compilers
_LT_TAGVAR(whole_archive_flag_spec, $1)='$wl--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; func_echo_all \"$new_convenience\"` $wl--no-whole-archive'
@@ -6450,7 +6460,7 @@ if test yes != "$_lt_caught_CXX_error"; then
;;
esac
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl--rpath $wl$libdir'
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath $wl$libdir'
_LT_TAGVAR(export_dynamic_flag_spec, $1)=&
Re: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux
Something wrong with this patch? Christian On 09/21/2012 10:34 AM, Christian Rössel wrote: Wrong list in the first place, sorry. Christian Original Message Subject: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux Date: Tue, 18 Sep 2012 18:38:20 -0700 From: Christian Rössel To: libtool CC: t...@subnetz.org Dear all, please find attached a patch that fixes the erroneous detection of PIC flags in case when CXX is a MPI wrapper that uses pgCC or pgcpp on GNU/Linux as well as the wrong rpath option. The testsuite.log output was created by configuring with CC=pgcc CXX=pgCC F77=pgf77 FC=pgf90 and running make check. Is this the supposed way to do it? Compiler version is 10.1-0. There were two unexpected failures, in the patched as well as in the unpatched version: 110: C++ exception handling FAILED (exceptions.at:385) 121: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43) BTW, is there a recommendation whether or not to use tabs for indentation in libtool.m4? Thanks, Christian -- Dipl-Phys. Christian Rössel Forschungszentrum Jülich GmbH Jülich Supercomputing Centre Telefon: +1 541 346 2484 E-Mail: c.roes...@fz-juelich.de Internet: http://www.fz-juelich.de/jsc Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt Kennen Sie schon unsere app? http://www.fz-juelich.de/app -- Dipl-Phys. Christian Rössel Forschungszentrum Jülich GmbH Jülich Supercomputing Centre Telefon: +1 541 346 2484 E-Mail: c.roes...@fz-juelich.de Internet: http://www.fz-juelich.de/jsc
Re: [PATCH] Add support for Intel MPI fortran compiler
Ward, On 10/07/2013 03:11 PM, Ward Poelmans wrote: In the check for static/shared libraries, the Intel MPI fortran compiler is not detected. MPI compiler wrappers using Intel compilers are already handled, at least for $host_os in linux* | k*bsd*-gnu | kopensolaris*-gnu). For libtool 2.4.2., see line 4403-4407 in libltdl/m4/libtool.m4: *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' ;; See also https://lists.gnu.org/archive/html/libtool/2010-12/msg00031.html Christian --- m4/libtool.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 80d7e44..246a337 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -4443,7 +4443,7 @@ m4_if([$1], [CXX], [ ;; # icc used to be incompatible with GCC. # ICC 10 doesn't accept -KPIC any more. - icc* | ifort*) + icc* | ifort* | mpif77* | mpif90* | mpifc* | mpiifort*) _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' @@ -4909,7 +4909,7 @@ _LT_EOF tmp_addflag=' -i_dynamic' ;; efc*,ia64* | ifort*,ia64*) # Intel Fortran compiler on ia64 tmp_addflag=' -i_dynamic -nofor_main' ;; - ifc* | ifort*) # Intel Fortran compiler + ifc* | ifort* | mpif77* | mpif90* | mpifc* | mpiifort*) # Intel Fortran compiler tmp_addflag=' -nofor_main' ;; lf95*) # Lahey Fortran 8.1 _LT_TAGVAR(whole_archive_flag_spec, $1)=
Re: [PATCH] Add support for Intel MPI fortran compiler
Brooks, On 10/09/2013 12:23 AM, Brooks Moses wrote: On 10/07/2013 06:11 AM, Ward Poelmans wrote: In the check for static/shared libraries, the Intel MPI fortran compiler is not detected. Thanks, but a couple of things don't look quite right here @@ -4443,7 +4443,7 @@ m4_if([$1], [CXX], [ ;; # icc used to be incompatible with GCC. # ICC 10 doesn't accept -KPIC any more. - icc* | ifort*) + icc* | ifort* | mpif77* | mpif90* | mpifc* | mpiifort*) "mpif77" is a commonly-used generic name; there's no assurance this is the Intel version (unless I'm missing something). that's correct, checking for mpi* is IMO a bad idea regarding libtool. In case of MPI and non-GCC Fortran compilers, libtool currently does a 'case `$CC -V 2>&1 | sed 5q` in' and compares against compiler vendor names to set lt_prog_compiler_ *. This is IMO error-prone and duplication as the functionality is already there in the 'case $cc_basename' case statements. What libtool really needs to know if used with MPI compiler wrappers, is the cc_basename of the compiler used by the MPI implementation. This could be implemented by extending _LT_CC_BASENAME. What do you think? See also: https://lists.gnu.org/archive/html/libtool/2010-12/msg00031.html https://lists.gnu.org/archive/html/libtool/2012-09/msg00030.html Christian Also, as per the Intel documentation I'm aware of, all of these except mpiifort* use GCC, not Intel's compilers, as the underlying compiler; do they actually need the special handling here? http://software.intel.com/sites/products/documentation/hpc/ics/impi/41/lin/Reference_Manual/Compiler_Commands.htm It also looks like you're missing mpiicc* from the list here (and mpiicpc* is also missing; it should be added with icpc* at line 4155). @@ -4909,7 +4909,7 @@ _LT_EOF tmp_addflag=' -i_dynamic' ;; efc*,ia64* | ifort*,ia64*)# Intel Fortran compiler on ia64 tmp_addflag=' -i_dynamic -nofor_main' ;; -ifc* | ifort*)# Intel Fortran compiler +ifc* | ifort* | mpif77* | mpif90* | mpifc* | mpiifort*)# Intel Fortran compiler Likewise here, with regards to mpif77*/mpif90*/mpifc*. Do these actually need the special handling, and are we sure this will only be triggered by Intel's mpif77? Thanks, - Brooks
Re: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux
Brooks, On 10/10/2013 12:44 AM, Brooks Moses wrote: Christian, I'm going through old libtool patches that haven't been reviewed, and came across this one. (Sorry that these have been ignored so long.) On 09/21/2012 10:34 AM, Christian Rössel wrote: please find attached a patch that fixes the erroneous detection of PIC flags in case when CXX is a MPI wrapper that uses pgCC or pgcpp on GNU/Linux as well as the wrong rpath option. I do have one small question about the patch, before I commit it: -case `$CC -V 2>&1 | sed 5q` in +case `$CC -V 2>&1` in You make this change in a couple of places where we match verbose compiler output looking for (among other things) "*Portland\ Group*". The "sed 5q" simply has the effect of trimming off the first 5 lines of the output and ignoring the rest -- presumably to avoid spurious matches to things in later output. Is this change required in order to correctly match the Portland Group compilers? That is, is the expected "*Portland\ Group*" coming somewhere after the first five lines? That seems odd. the change is required when using MPICH2 (tested with version 1.3.2p1) as the output of mpicxx -V 2>&1 | sed 5q is /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12 /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13 /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12 The rest of the patch looks good to me, though I'd be curious to see a copy of the "$CC -V" output that you're matching. (In particular, I'd like to see output from both pre-version-6 and post-version-6 versions to see how the version-matching relates to the expected input.) Most of the patch is copy-paste from locations where cc_basename matches "pgCC* | pgcpp*)", the version-matching was copied as well. As I wrote in [1], I'm not sure if copy-pasting is the best approach to deal with compilers used through a wrapper. Extending _LT_CC_BASENAME might be a more robust approach. If you prefer an improvement of _LT_CC_BASENAME over copy-pasting, please ignore my patch. Please let me know if patching _LT_CC_BASENAME is an option. Thanks, Christian [1] https://lists.gnu.org/archive/html/libtool-patches/2013-10/msg00021.html Also, thanks for the test reports that you included. Thanks, - Brooks
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote: > [ adding the libtool-patches list, moving libtool list to Bcc: so you > can omit it from followups ] > > Hello John, Christian, > > thanks to both of you for all your feedback so far. > > We have a pretty good idea of what is happening for the C compilers now, > but the C++ and the Fortran compilers still need research. Also, I'm > not sure yet how to integrate the -qnostaticlink flag automatically, so > for now let's do it manually. > > Below is a first cut at a patch to add support for BG to Libtool. > I would like you to test it for me. This is going to be a bit of work, > as it will involve several steps. Please try to follow them all. > > First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 > installed somewhere (below the same --prefix) and found early in $PATH. Hi Ralf, in order to configure autoconf I needed to install GNU m4. Then everything went fine. > Then, grab either the git master branch of the Libtool tree, or a > nightly snapshot; the Libtool homepage has a link. Extract the tarball. > > Apply the patch at the end of this message to the Libtool tree, then run > ./bootstrap I used the git branch but couldn't apply the patch via patch -p1 < patchfile. So I did it manually. > If there are any problems or error messages, stop right here and report > back with them. Otherwise, continue: There was one error I assume is negligible: cd ./doc && \ makeinfo --no-headers -o notes.txt notes.texi /bin/sh: makeinfo: command not found > Create six build trees and build and run the Libtool test suites > with each of the compiler combinations (the following assumes > Bourne-shell syntax): > > mkdir build-gcc build-xl build-bgcc build-bgxl build-mpigcc build-mpixl > > # GCC, non-BG > cd build-gcc > ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no configure complains "configure: error: cannot find sources (libtoolize.in) in .. or .." There is a libtoolize.m4sh in .. but not a libtoolize.in. What shall I do? Cheers, Christian --- --- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Prof. Dr. Sebastian M. Schmidt --- ---
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote: > * Christian Rössel wrote on Tue, Apr 21, 2009 at 10:28:37AM CEST: >> Ralf Wildenhues wrote: >> >>> If there are any problems or error messages, stop right here and report >>> back with them. Otherwise, continue: >> There was one error I assume is negligible: >> cd ./doc && \ >> makeinfo --no-headers -o notes.txt notes.texi >> /bin/sh: makeinfo: command not found > > Yes, the error itself should be harmless, but it has the problem of > causing some other files not to be built. Please re-bootstrap with > MAKEINFO=true ./bootstrap > > then there should be a libtoolize.in file afterwards, and you should be > able to go on with the previous list, unless there are further errors. Hi Ralf, re-boostrapping works now but the missing makeinfo causes new problems: /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: line 54: makeinfo: command not found WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[2]: *** [../doc/libtool.info] Error 1 I will install makeinfo to avoid further problems. > I'll apply the patch below to let the impact of missing 'makeinfo' be > less of a problem, if you let me know which email address to add to > THANKS. Use christian.roes...@gmx.de Cheers, Christian
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote: > First, please ensure that you have Autoconf 2.63 and Automake 1.10.2 > installed somewhere (below the same --prefix) and found early in $PATH. Hi Ralf, why do I need to install them below the *same* prefix. Is this a general requirement? What will happen if I use distinct prefixes but put both bindirs into my PATH? Regards, Christian
Re: Fortran libraries on the Blue Gene with mpi
Christian Rössel wrote: > Ralf Wildenhues wrote: >> * Christian Rössel wrote on Tue, Apr 21, 2009 at 10:28:37AM CEST: >>> Ralf Wildenhues wrote: >>> >>>> If there are any problems or error messages, stop right here and report >>>> back with them. Otherwise, continue: >>> There was one error I assume is negligible: >>> cd ./doc && \ >>> makeinfo --no-headers -o notes.txt notes.texi >>> /bin/sh: makeinfo: command not found >> Yes, the error itself should be harmless, but it has the problem of >> causing some other files not to be built. Please re-bootstrap with >> MAKEINFO=true ./bootstrap >> >> then there should be a libtoolize.in file afterwards, and you should be >> able to go on with the previous list, unless there are further errors. > > Hi Ralf, > > re-boostrapping works now but the missing makeinfo causes new problems: > > /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: > line 54: makeinfo: command not found > WARNING: `makeinfo' is missing on your system. You should only need it if > you modified a `.texi' or `.texinfo' file, or any other file > indirectly affecting the aspect of the manual. The spurious > call might also be the consequence of using a buggy `make' (AIX, > DU, IRIX). You might want to install the `Texinfo' package or > the `GNU make' package. Grab either from any GNU archive site. > make[2]: *** [../doc/libtool.info] Error 1 > > I will install makeinfo to avoid further problems. Hi Ralf, I installed makeinfo (texinfo-4.13) and re-bootstrapped ... > # GCC, non-BG > cd build-gcc > ../configure CC=gcc CXX=g++ F77=g77 FC=gfortran GCJ=no > make ... and ran into the next error: /u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/libltdl/config/missing: line 54: help2man: command not found WARNING: `help2man' is missing on your system. You should only need it if you modified a dependency of a manual page. You may need the `Help2man' package in order for those modifications to take effect. You can get `Help2man' from any GNU archive site. gmake[2]: *** [../doc/libtoolize.1] Error 1 After installing help2man I was able to run the tests. Cheers, Christian
Re: Fortran libraries on the Blue Gene with mpi
Ralf Wildenhues wrote:
> * Christian Rössel wrote on Mon, Apr 27, 2009 at 05:33:33PM CEST:
>> Ralf Wildenhues wrote:
>>>>> # XL, BG
>>>>> cd build-bgxl
>>>>> ../configure CC=bgxlc CXX=bgxlC F77=bgfort FC=bgxlf95 GCJ=no \
>>>>>LDFLAGS=-qnostaticlink
>>>>> make
>>>>> make -k check VERBOSE=yes 2>&1 | tee checklog-bgxl-1
>>>>> cd ..
>>> This is where things start to get interesting.
>> With the bg* compilers we build programs that are supposed to be run on
>> the compute nodes. They may also run on the login-nodes, but you can't
>> take that for granted (AFAIR the error "Illegal instruction" appears if
>> you try to run a compute node program on a login node).
>
> Ah! I completely misunderstood that. That means that all those builds
> should run with cross-compiling enabled. Cross compilation mode is
> enabled when --host is passed (and differs from either the passed
> --build flag, or whatever configure computes as the build name);
> you can also force cross compilation mode through the hack of passing
> cross_compiling=yes
>
> to configure. The --host argument will also cause configure to look for
> all tool chain programs with a $host- prefix, in this case, with
> --host=powerpc-bgp-linux that would be powerpc-bgp-linux-gcc etc.
>
>> As all tests run
>> on the login-nodes, we should expect failures. Also, a test that
>> succeeds on the login node may not succeed on the compute node. IMHO all
>> test programs build with bg* and mpi* compilers should be run on the
>> compute nodes, not on the login nodes.
>
> Well, in this case they should not be run at all, at least not those
> that are run as part of the configure script.
>
>> To run a program on the compute nodes you write a batch script and
>> submit it to a queue. This process unfortunately differs from machine to
>> machine. It is also not sensible to submit many small jobs to the queue
>> as one job allocates at least 128 nodes.
>
> :-)
>
>> Maybe there is a way of calling
>> all tests from a single batch script so that one has to submit only one job.
>
> Not really. For those that failed on the login nodes, you can try to
> submit one or two to the queue; if they then pass, I'd be pretty
> confident that the others will work, too.
Hi Ralf, hi John,
I configured build-bgxl for cross compiling, reran the tests and found
two illegal instruction in the checklog:
f77demo-exec.test: === Running f77demo-exec.test
f77demo-exec.test: === Executing uninstalled programs in build-bgxl3
tests/defs: line 1132: 10739 Illegal instruction tests/f77demo/fprogram
f77demo-exec.test: ../tests/f77demo-exec.test: cannot execute
tests/f77demo/fprogram
f77demo-exec.test: === This may be ok since you seem to be cross-compiling.
fcdemo-exec.test: === Running fcdemo-exec.test
fcdemo-exec.test: === Executing uninstalled programs in build-bgxl3
tests/defs: line 1132: 20901 Illegal instruction tests/fcdemo/fprogram
fcdemo-exec.test: ../tests/fcdemo-exec.test: cannot execute
tests/fcdemo/fprogram
fcdemo-exec.test: === This may be ok since you seem to be cross-compiling.
I wanted to run these two on the compute nodes, but after finishing the
tests, the programs were gone.
>>> Test failures:
>>>
>>> - f77demo-* in the old testsuite
>>> This is because the bgfort command does not exist.
>>> It was a typo, should have been F77=bgfort77 or F77=bgf77 or F77=bgxlf
>>> I guess. If you have energy left, here's how you can rerun those
>>> tests:
>>>
>>>cd build-bgxl
>>>../configure CC=bgxlc CXX=bgxlC F77=bgfort77 FC=bgxlf95 GCJ=no \
>>> LDFLAGS=-qnostaticlink
>>>gmake
>>>gmake -k check VERBOSE=yes TESTSUITEFLAGS='-k F77' TESTS="\
>>> tests/f77demo-static.test \
>>> tests/f77demo-make.test \
>>> tests/f77demo-exec.test \
>>> tests/f77demo-conf.test \
>>> tests/f77demo-make.test \
>>> tests/f77demo-exec.test \
>>> tests/f77demo-shared.test \
>>> tests/f77demo-make.test \
>>> tests/f77demo-exec.test"
>> Please find the results attached (checklog-bgxl-2).
>
> Thanks. f77demo-exec.test fails after f77demo-static.test, and
> f77demo-make.test fails after f77demo-{conf,shared}.test. The first
> failure is an "Illegal instruction" again, for which we have an
> explanation now; the other two are again:
>
> /bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bi
