from:"Christian Rössel"

Re: [PATCH] Add support for Intel MPI fortran compiler

2013-10-14 Thread Christian Rössel


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

2013-10-14 Thread Christian Rössel


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 21 | 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

2013-10-14 Thread Christian Rössel


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 21 | sed 5q` in
+case `$CC -V 21` 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 21 | 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: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux

2012-10-15 Thread Christian Rössel


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 c.roes...@fz-juelich.de
To: libtool libt...@gnu.org
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

Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux

2012-09-21 Thread Christian Rössel


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 c.roes...@fz-juelich.de
To: libtool libt...@gnu.org
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 21 | sed 5q` in
+	case `$CC -V 21` 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 21 | sed 5q` in
+	case `$CC -V 21` 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)='$wl--export-dynamic'
 	_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'
 ;;
@@ -6486,7 +6496,7 @@ if test yes != $_lt_caught_CXX_error; then
 	fi
 	;;
 	  *)
-	case `$CC -V

Re: PIC flags not found for mpif77(ifort)

2010-12-17 Thread Christian Rössel

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)

2010-12-16 Thread 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

 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)

2010-12-16 Thread Christian Rössel

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)

2010-12-16 Thread Christian Rössel

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)

2010-12-15 Thread Christian Rössel

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: Fortran libraries on the Blue Gene with mpi

2009-04-29 Thread Christian Rössel

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 21 | 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/bin/ld: attempted
static link of dynamic object `./.libs/libfoo.so'

I still don't know the cause for this; but at least the F77 cases look
just like the FC cases.

Can you post the output of the following?

cd build-bgxl/tests/fcdemo
/bin/sh ./libtool --mode=link bgxlf95 -Wc,-v -g -qnostaticlink -o
fprogram fprogram.o libfoo.la libfoo3.la -ldl

libtool: link:
LD_RUN_PATH=/u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/build-bgxl3/_inst/lib:
bgxlf95 -Wl,-v -g -qnostaticlink -o .libs/fprogram fprogram.o
./.libs/libfoo.so
/u/fzj301zm/BlueGene/fortran_libraries_on_the_blue_gene_with_mpi/libtool/build-bgxl3/tests/fcdemo/.libs/libfoo2.so
./.libs/libfoo3.so -ldl
/bgsys/drivers/ppcfloor/gnu-linux/powerpc

Re: Fortran libraries on the Blue Gene with mpi

2009-04-22 Thread Christian Rössel

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

2009-04-22 Thread Christian Rössel

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

2009-04-22 Thread Christian Rössel

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: [PATCH] Add support for Intel MPI fortran compiler

Re: [PATCH] Add support for Intel MPI fortran compiler

Re: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux

Re: Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux

Fwd: Fix PIC flags with MPI wrappers using Portland C++ on GNU/Linux

Re: PIC flags not found for mpif77(ifort)

Re: PIC flags not found for mpif77(ifort)

Re: PIC flags not found for mpif77(ifort)

Re: PIC flags not found for mpif77(ifort)

Re: PIC flags not found for mpif77(ifort)

Re: Fortran libraries on the Blue Gene with mpi

Re: Fortran libraries on the Blue Gene with mpi

Re: Fortran libraries on the Blue Gene with mpi

Re: Fortran libraries on the Blue Gene with mpi

14 matches

Site Navigation

Mail list logo

Footer information