Re: [OMPI devel] "make check" (libtool) failure on Linux/ppc w/ XLC (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

While I still don't know the root cause, the following diff between the 
libtool-generated wrappers for a gcc and xlc build make the cause of the 
"make check" failure fairly obvious:


--- BLD-gcc/ompi/debuggers/predefined_gap_test  2010-08-26 
20:49:53.524662327 -0500
+++ BLD-xlc_r/ompi/debuggers/predefined_gap_test2010-08-26 
20:48:00.440815415 -0500

@@ -104,15 +104,6 @@


  if test -f "$progdir/$program"; then
-# Add our own library path to LD_LIBRARY_PATH
-
LD_LIBRARY_PATH="/home/hargrove/tmp/openmpi-1.5rc5/BLD/ompi/.libs:$LD_LIBRARY_PATH"

-
-# Some systems cannot cope with colon-terminated LD_LIBRARY_PATH
-# The second colon is a workaround for a bug in BeOS R4 sed
-LD_LIBRARY_PATH=`$ECHO "X$LD_LIBRARY_PATH" | $Xsed -e 's/::*$//'`
-
-export LD_LIBRARY_PATH
-
if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
  # Run the actual program with our arguments.


-Paul

Paul H. Hargrove wrote:
I am now looking at using IBM's XLC compilers for ILP32 builds on the 
same Linux/PPC64 platform for which I've reported some XLC/LP64 bugs.


What I find now is that "make check" is failing with the loader unable 
to find libmpi.so.0.

This is with both 1.5rc5 and 1.4.3rc1.
This occurs with xlc, but things are just fine with gcc.

$ uname -a
Linux login1 2.6.16.60-0.67.1-ppc64 #1 SMP Thu Aug 5 10:54:46 UTC 2010
ppc64 ppc64 ppc64 GNU/Linux

$ which xlc
/soft/apps/ibmcmp-aug2010/vac/bg/9.0/bin/xlc
$ xlc -qversion
IBM XL C/C++ Advanced Edition for Blue Gene/P, V9.0
Version: 09.00..0009

$ gcc --version
gcc (GCC) 4.1.2 20070115 (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There 
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


$ /lib64/libc.so.6
GNU C Library stable release version 2.4 (20090904), by Roland McGrath
et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for ppc64-suse-linux.
Compiled by GNU CC version 4.1.2 20070115 (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2009-09-04.
Available extensions:
  crypt add-on version 2.1 by Michael Glad and others
  GNU Libidn by Simon Josefsson
  GNU libio by Per Bothner
  NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
  Native POSIX Threads Library by Ulrich Drepper et al
  BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
.

Here is the configure command:

$ [path_to]/configure --with-contrib-vt-flags=--with-platform=linux 
CC=xlc_r CXX=xlC_r F77=xlf FC=xlf90


The problem exists with both 1.5rc5 and 1.4.3rc1.

Here is the failure from 1.4.3.rc1:

$ make check
[...]
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype'

make[3]: `checksum' is up to date.
make[3]: `position' is up to date.
make[3]: `to_self' is up to date.
make[3]: `ddt_pack' is up to date.
make[3]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype'

make  check-TESTS
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype'
/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype/.libs/checksum: 
error while loading shared libraries: libmpi.so.0: cannot open shared 
object file: No such file or directory

FAIL: checksum
/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype/.libs/position: 
error while loading shared libraries: libmpi.so.0: cannot open shared 
object file: No such file or directory

FAIL: position

2 of 2 tests failed
Please report to http://www.open-mpi.org/community/help/




Here is 1.5.rc5, which I suspect differs only because the two releases 
contain different tests:


$ make check
[...]
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers'

 CC predefined_gap_test.o
 CCLD   predefined_gap_test
 CC dlopen_test-dlopen_test.o
 CCLD   dlopen_test
make[3]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers'

make  check-TESTS
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers'
/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers/.libs/predefined_gap_test: 
error while loading shared libraries: libmpi.so.0: cannot open shared 
object file: No such file or directory

FAIL: predefined_gap_test
Trying to lt_dlopen file with dladvise_local: ./libompi_dbg_msgq
File opened with dladvise_local, all passed
PASS: dlopen_test

1 of 2 tests failed
Please report to http://www.open-mpi.org/community/help/
=

[OMPI devel] "make check" (libtool) failure on Linux/ppc w/ XLC (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

I am now looking at using IBM's XLC compilers for ILP32 builds on the 
same Linux/PPC64 platform for which I've reported some XLC/LP64 bugs.


What I find now is that "make check" is failing with the loader unable 
to find libmpi.so.0.

This is with both 1.5rc5 and 1.4.3rc1.
This occurs with xlc, but things are just fine with gcc.

$ uname -a
Linux login1 2.6.16.60-0.67.1-ppc64 #1 SMP Thu Aug 5 10:54:46 UTC 2010
ppc64 ppc64 ppc64 GNU/Linux

$ which xlc
/soft/apps/ibmcmp-aug2010/vac/bg/9.0/bin/xlc
$ xlc -qversion
IBM XL C/C++ Advanced Edition for Blue Gene/P, V9.0
Version: 09.00..0009

$ gcc --version
gcc (GCC) 4.1.2 20070115 (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /lib64/libc.so.6
GNU C Library stable release version 2.4 (20090904), by Roland McGrath
et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for ppc64-suse-linux.
Compiled by GNU CC version 4.1.2 20070115 (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2009-09-04.
Available extensions:
  crypt add-on version 2.1 by Michael Glad and others
  GNU Libidn by Simon Josefsson
  GNU libio by Per Bothner
  NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
  Native POSIX Threads Library by Ulrich Drepper et al
  BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
.

Here is the configure command:

$ [path_to]/configure --with-contrib-vt-flags=--with-platform=linux 
CC=xlc_r CXX=xlC_r F77=xlf FC=xlf90


The problem exists with both 1.5rc5 and 1.4.3rc1.

Here is the failure from 1.4.3.rc1:

$ make check
[...]
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype'

make[3]: `checksum' is up to date.
make[3]: `position' is up to date.
make[3]: `to_self' is up to date.
make[3]: `ddt_pack' is up to date.
make[3]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype'

make  check-TESTS
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype'
/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype/.libs/checksum: 
error while loading shared libraries: libmpi.so.0: cannot open shared 
object file: No such file or directory

FAIL: checksum
/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r/test/datatype/.libs/position: 
error while loading shared libraries: libmpi.so.0: cannot open shared 
object file: No such file or directory

FAIL: position

2 of 2 tests failed
Please report to http://www.open-mpi.org/community/help/




Here is 1.5.rc5, which I suspect differs only because the two releases 
contain different tests:


$ make check
[...]
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers'

 CC predefined_gap_test.o
 CCLD   predefined_gap_test
 CC dlopen_test-dlopen_test.o
 CCLD   dlopen_test
make[3]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers'

make  check-TESTS
make[3]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers'
/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r/ompi/debuggers/.libs/predefined_gap_test: 
error while loading shared libraries: libmpi.so.0: cannot open shared 
object file: No such file or directory

FAIL: predefined_gap_test
Trying to lt_dlopen file with dladvise_local: ./libompi_dbg_msgq
File opened with dladvise_local, all passed
PASS: dlopen_test

1 of 2 tests failed
Please report to http://www.open-mpi.org/community/help/



As I said above, the problem is NOT occuring w/ gcc.  So, I've attached 
the "./libtool --config" output for the xlc and gcc builds, which I see 
differ in more ways than I would have expected.



-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900


# Whether or not to build shared libraries.
build_libtool_libs=yes

# Whether or not to build static libraries.
build_old_libs=no

# A BSD- or MS-compatible name lister.
NM="/usr/bin/nm -B"

# Which release of libtool.m4 was used?
macro_version=2.2.6b
macro_revision=1.3017

# Assembler program.
AS=as

# DLL creation program.
DLLTOOL=dlltool

# Object dumper program.
OBJDUMP=objdump

# What type of objects to build.
pic_mode=default

# Whether or not to optimize for fast installation.
fast_install=needles

[OMPI devel] Failure (libtool?) to build F90 bindings w/ XLC/PPC64 (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

One of the platforms I've been testing is a Linux/PPC64 (which happens 
to be the front-end to a BG/P, but don't be confused by that - I am NOT 
trying to build for the BG/P).  On the system are IBM's XLC compilers 
(also sold under the ABSoft name).  When passing "-q64" to the xlc 
compilers to get an LP64 ABI (default is ILP32), it seems that the 
scripts for constricting the F90 bindings somehow end up passing the 
"-q64" to /usr/bin/ld, which is not happy.


If I don't set {C,CXX,F,FC}FLAGS=-q64 then there is no problem building 
the F90 bindings (for ILP32 ABI).


If I --disable-mpi-f90 the build is fine (except for the atomic test 
failure from "make check", reported in  
http://www.open-mpi.org/community/lists/devel/2010/08/8369.php)


Here are the details of the platform:

$ uname -a
Linux login1 2.6.16.60-0.67.1-ppc64 #1 SMP Thu Aug 5 10:54:46 UTC 2010
ppc64 ppc64 ppc64 GNU/Linux

$ which xlc
/soft/apps/ibmcmp-aug2010/vac/bg/9.0/bin/xlc
$ xlc -qversion
IBM XL C/C++ Advanced Edition for Blue Gene/P, V9.0
Version: 09.00..0009

$ /lib64/libc.so.6
GNU C Library stable release version 2.4 (20090904), by Roland McGrath
et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for ppc64-suse-linux.
Compiled by GNU CC version 4.1.2 20070115 (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2009-09-04.
Available extensions:
   crypt add-on version 2.1 by Michael Glad and others
   GNU Libidn by Simon Josefsson
   GNU libio by Per Bothner
   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
   Native POSIX Threads Library by Ulrich Drepper et al
   BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
.

Here is the configure command:

$ [path_to]/configure --with-contrib-vt-flags=--with-platform=linux 
CC=xlc_r CXX=xlC_r F77=xlf FC=xlf90 CFLAGS=-q64 CXXFLAGS=-q64 
FFLAGS=-q64 FCFLAGS=-q64


The problem exists with both 1.5rc5 and 1.4.3rc1.

Here is the failure from 1.4.3.rc1:

$ make
[...]
make[4]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/ompi/mpi/f90'
/bin/sh ../../../libtool   --mode=link xlf90 -I../../../ompi/include 
-I../../../../ompi/include -I. -I../../../../ompi/mpi/f90 
-I../../../ompi/mpi/f90  -q64 -version-info 0:0:0  -export-dynamic   -o 
libmpi_f90.la -rpath /usr/local/lib mpi.lo mpi_sizeof.lo 
mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo mpi_testsome_f90.lo 
mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo 
mpi_wtime_f90.lo   ../../../ompi/libmpi.la -lnsl -lutil
libtool: link: /usr/bin/ld -m elf64ppc -shared  .libs/mpi.o 
.libs/mpi_sizeof.o .libs/mpi_comm_spawn_multiple_f90.o 
.libs/mpi_testall_f90.o .libs/mpi_testsome_f90.o .libs/mpi_waitall_f90.o 
.libs/mpi_waitsome_f90.o .libs/mpi_wtick_f90.o .libs/mpi_wtime_f90.o   
-L/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/orte/.libs 
-L/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/opal/.libs 
../../../ompi/.libs/libmpi.so 
/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/orte/.libs/libopen-rte.so 
/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/opal/.libs/libopen-pal.so 
-ldl -lnsl -lutil  -q64   -soname libmpi_f90.so.0 -o 
.libs/libmpi_f90.so.0.0.0

/usr/bin/ld: unrecognized option '-q64'
/usr/bin/ld: use the --help option for usage information
make[4]: *** [libmpi_f90.la] Error 1
make[4]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/ompi/mpi/f90'

make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/ompi/mpi/f90'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/ompi/mpi/f90'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.4.3rc1/BLD-xlc_r-64/ompi'

make: *** [all-recursive] Error 1



Here is the failure from 1.5rc5 (including re-run w/ V=1)

$ make
[...]
make[4]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r-64/ompi/mpi/f90'

 FCLD   libmpi_f90.la
/usr/bin/ld: unrecognized option '-q64'
/usr/bin/ld: use the --help option for usage information
make[4]: *** [libmpi_f90.la] Error 1
make[4]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r-64/ompi/mpi/f90'

make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r-64/ompi/mpi/f90'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r-64/ompi/mpi/f90'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r-64/ompi'

make: *** [all-recursive] Error 1
$ make V=1
[...]
make[4]: Entering directory 
`/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-xlc_r-64/ompi/mpi/f90'
/

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23665

[Ralph Castain]

Did you put it in the Makefile.am EXTRA_DIST?

On Aug 26, 2010, at 1:39 PM, Ethan Mallove wrote:

> This fixes Libtool for an SVN checkout, but does not seem to get into
> the nightly trunk tarball.  Why is that?
> 
> -Ethan
> 
> On Wed, Aug/25/2010 03:40:18PM, emall...@osl.iu.edu wrote:
>> Author: emallove
>> Date: 2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
>> New Revision: 23665
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/23665
>> 
>> Log:
>> Patch `ltmain.sh` in `autogen.sh` per this Libtool thread:
>> http://www.mail-archive.com/libtool@gnu.org/msg11249.html
>> 
>> Added:
>>   trunk/config/ltmain_pgi_tp.diff
>> Text files modified: 
>>   trunk/autogen.sh | 8 
>>   1 files changed, 8 insertions(+), 0 deletions(-)
>> 
>> Modified: trunk/autogen.sh
>> ==
>> --- trunk/autogen.sh (original)
>> +++ trunk/autogen.sh 2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
>> @@ -11,6 +11,7 @@
>> # Copyright (c) 2004-2005 The Regents of the University of California.
>> # All rights reserved.
>> # Copyright (c) 2007-2010 Cisco Systems, Inc.  All rights reserved.
>> +# Copyright (c) 2010  Oracle and/or its affiliates.  All rights 
>> reserved.
>> # $COPYRIGHT$
>> # 
>> # Additional copyrights may follow
>> @@ -442,6 +443,13 @@
>> 
>>  echo "** Adjusting libltdl for OMPI :-("
>> 
>> +echo "   ++ patching PGI -tp bug in ltmain.sh"
>> +if test -z "`grep -w tp config/ltmain.sh`"; then
>> +patch -N -p0 < config/ltmain_pgi_tp.diff
>> +else
>> +echo "  -- your libtool doesn't need this! yay!"
>> +fi
>> +
>> echo "   ++ preopen error masking ib libltdl"
>> if test -r opal/libltdl/loaders/preopen.c; then
>> patch -N -p0 < config/libltdl-preopen-error.diff
>> 
>> Added: trunk/config/ltmain_pgi_tp.diff
>> ==
>> --- (empty file)
>> +++ trunk/config/ltmain_pgi_tp.diff  2010-08-25 15:40:17 EDT (Wed, 25 Aug 
>> 2010)
>> @@ -0,0 +1,11 @@
>> +--- config/ltmain.sh
>>  config/ltmain.sh
>> +@@ -4765,7 +4765,7 @@
>> +   # -p, -pg, --coverage, -fprofile-* pass through profiling flag for 
>> GCC
>> +   # @file GCC response files
>> +   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
>> +-  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
>> ++  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp|-tp=*)
>> + func_quote_for_eval "$arg"
>> +arg="$func_quote_for_eval_result"
>> + func_append compile_command " $arg"
>> ___
>> svn-full mailing list
>> svn-f...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] common_sm_mmap.c: wrong args to orte_show_help() (1.5rc5 and 1.4.3rc1)

[Samuel K. Gutierrez]

Will do.

Sam

On Aug 26, 2010, at 2:08 PM, Jeff Squyres wrote:


I think Sam already submitted CMR's for 1.5:

 https://svn.open-mpi.org/trac/ompi/ticket/2545

Sam -- can you construct an equivalent for v1.4 and CC Paul so that  
he knows not to follow up on it?


Thanks!


On Aug 26, 2010, at 3:56 PM, Paul H. Hargrove wrote:

The warnings below have appeared in some of my other testing  
results.  However, I now know what they correspond to.


In both 1.5rc5 and 1.4.3rc1 there are two calls to orte_show_help()  
that are passing orte_process_info.nodename as the third argument,  
where a _Bool is expected.  It looks to me as if the third argument  
is actually just missing from these 2 calls.


-Paul

For 1.4.3rc1:

"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 111.41:  
1506-280 (W) Function argument assignment between types "_Bool" and  
"char*" is not allowed.
"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 136.45:  
1506-280 (W) Function argument assignment between types "_Bool" and  
"char*" is not allowed.


For 1.5rc5:

"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 110.41:  
1506-280 (W) Function argument assignment between types "_Bool" and  
"char*" is not allowed.
"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 135.45:  
1506-280 (W) Function argument assignment between types "_Bool" and  
"char*" is not allowed.


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] "make check" (libtool?) failure on Solaris/SPARC (1.5rc5 and 1.4.3rc1)

[Ralf Wildenhues]

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 10:14:22PM CEST:
>  I just had a thought on this one:  In my environment on this
> platform I have LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 set.  It
> seems possible to me that this is causing the loader to ignore the
> LD_LIBRARY_PATH setting that libtool's wrapper script sets when
> executing uninstalled programs in the build directory, as during
> "make check".
>  So, I tried removing these from my environment and editing
> ~/.bashrc not to set them.  The result is a SUCCESSful "make check"!

Cool.  We need to fix that in Libtool then.

Thanks for tracking this down!
Ralf

Re: [OMPI devel] "make check" (libtool?) failure on Solaris/SPARC (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

Paul H. Hargrove wrote:


Ralf Wildenhues wrote:

Hello Paul,

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 01:58:11AM CEST:
 

I have been able to configure and build both 1.5rc5 and 1.4.3rc1 on
Solaris 10 for SPARC, using Sun C 5.10.
I have also build 1.5rc5 w/ gcc-3.3.2 (and expect 1.4.3rc1 to build
w/ gcc as well, once I have time)

All 3 builds fail "make check" in a way that suggests to me that
libtool is not working correctly on this platform.



Can you send output of './libtool --config' for the platforms?

Thanks,
Ralf
  


Requested output is attached.

-Paul



Ralph,

 I just had a thought on this one:  In my environment on this platform 
I have LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 set.  It seems possible 
to me that this is causing the loader to ignore the LD_LIBRARY_PATH 
setting that libtool's wrapper script sets when executing uninstalled 
programs in the build directory, as during "make check".
 So, I tried removing these from my environment and editing ~/.bashrc 
not to set them.  The result is a SUCCESSful "make check"!


-Paul


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] common_sm_mmap.c: wrong args to orte_show_help() (1.5rc5 and 1.4.3rc1)

[Jeff Squyres]

I think Sam already submitted CMR's for 1.5:

  https://svn.open-mpi.org/trac/ompi/ticket/2545

Sam -- can you construct an equivalent for v1.4 and CC Paul so that he knows 
not to follow up on it?

Thanks!


On Aug 26, 2010, at 3:56 PM, Paul H. Hargrove wrote:

> The warnings below have appeared in some of my other testing results.  
> However, I now know what they correspond to.
> 
> In both 1.5rc5 and 1.4.3rc1 there are two calls to orte_show_help() that are 
> passing orte_process_info.nodename as the third argument, where a _Bool is 
> expected.  It looks to me as if the third argument is actually just missing 
> from these 2 calls.
> 
> -Paul
> 
> For 1.4.3rc1:
> 
> "../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 111.41: 1506-280 
> (W) Function argument assignment between types "_Bool" and "char*" is not 
> allowed.
> "../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 136.45: 1506-280 
> (W) Function argument assignment between types "_Bool" and "char*" is not 
> allowed.
> 
> For 1.5rc5:
> 
> "../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 110.41: 1506-280 
> (W) Function argument assignment between types "_Bool" and "char*" is not 
> allowed.
> "../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 135.45: 1506-280 
> (W) Function argument assignment between types "_Bool" and "char*" is not 
> allowed.
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] common_sm_mmap.c: wrong args to orte_show_help() (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

The warnings below have appeared in some of my other testing results.  
However, I now know what they correspond to.


In both 1.5rc5 and 1.4.3rc1 there are two calls to orte_show_help() that 
are passing orte_process_info.nodename as the third argument, where a 
_Bool is expected.  It looks to me as if the third argument is actually 
just missing from these 2 calls.


-Paul

For 1.4.3rc1:

"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 111.41: 
1506-280 (W) Function argument assignment between types "_Bool" and 
"char*" is not allowed.
"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 136.45: 
1506-280 (W) Function argument assignment between types "_Bool" and 
"char*" is not allowed.


For 1.5rc5:

"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 110.41: 
1506-280 (W) Function argument assignment between types "_Bool" and 
"char*" is not allowed.
"../../../../../ompi/mca/common/sm/common_sm_mmap.c", line 135.45: 
1506-280 (W) Function argument assignment between types "_Bool" and 
"char*" is not allowed.


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r23665

[Ethan Mallove]

This fixes Libtool for an SVN checkout, but does not seem to get into
the nightly trunk tarball.  Why is that?

-Ethan

On Wed, Aug/25/2010 03:40:18PM, emall...@osl.iu.edu wrote:
> Author: emallove
> Date: 2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
> New Revision: 23665
> URL: https://svn.open-mpi.org/trac/ompi/changeset/23665
> 
> Log:
> Patch `ltmain.sh` in `autogen.sh` per this Libtool thread:
> http://www.mail-archive.com/libtool@gnu.org/msg11249.html
> 
> Added:
>trunk/config/ltmain_pgi_tp.diff
> Text files modified: 
>trunk/autogen.sh | 8 
>1 files changed, 8 insertions(+), 0 deletions(-)
> 
> Modified: trunk/autogen.sh
> ==
> --- trunk/autogen.sh  (original)
> +++ trunk/autogen.sh  2010-08-25 15:40:17 EDT (Wed, 25 Aug 2010)
> @@ -11,6 +11,7 @@
>  # Copyright (c) 2004-2005 The Regents of the University of California.
>  # All rights reserved.
>  # Copyright (c) 2007-2010 Cisco Systems, Inc.  All rights reserved.
> +# Copyright (c) 2010  Oracle and/or its affiliates.  All rights reserved.
>  # $COPYRIGHT$
>  # 
>  # Additional copyrights may follow
> @@ -442,6 +443,13 @@
>  
>   echo "** Adjusting libltdl for OMPI :-("
>  
> +echo "   ++ patching PGI -tp bug in ltmain.sh"
> +if test -z "`grep -w tp config/ltmain.sh`"; then
> +patch -N -p0 < config/ltmain_pgi_tp.diff
> +else
> +echo "  -- your libtool doesn't need this! yay!"
> +fi
> +
>  echo "   ++ preopen error masking ib libltdl"
>  if test -r opal/libltdl/loaders/preopen.c; then
>  patch -N -p0 < config/libltdl-preopen-error.diff
> 
> Added: trunk/config/ltmain_pgi_tp.diff
> ==
> --- (empty file)
> +++ trunk/config/ltmain_pgi_tp.diff   2010-08-25 15:40:17 EDT (Wed, 25 Aug 
> 2010)
> @@ -0,0 +1,11 @@
> +--- config/ltmain.sh
>  config/ltmain.sh
> +@@ -4765,7 +4765,7 @@
> +   # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC
> +   # @file GCC response files
> +   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
> +-  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
> ++  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp|-tp=*)
> + func_quote_for_eval "$arg"
> +arg="$func_quote_for_eval_result"
> + func_append compile_command " $arg"
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full

Re: [OMPI devel] make install (libtool) failure on Solaris 10 (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

Ralf Wildenhues wrote:

* Ralf Wildenhues wrote on Thu, Aug 26, 2010 at 07:29:17AM CEST:
  

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 05:37:23AM CEST:


libtool: install: (cd /usr/local/pkg/ompi-1.5rc5/lib && { ln -s -f
libmpi.so.0.0.2 libmpi.so.0 || { rm -f libmpi.so.0 && ln -s
libmpi.so.0.0.2 libmpi.so.0; }; })
Usage: ln [-f] [-s] f1
  

[...]

  

This is due to an incomprehensibly stupid "ln" that cares about the
order of the "-s" and "-f" options:

$ rm -f b; touch a; ln -f -s a b
$ rm -f b; touch a; ln -s -f a b
Usage: ln [-f] [-s] f1
  ln [-f] [-s] f1 f2
  ln [-f] [-s] f1 ... fn d1

$ which ln
/usr/ucb/ln

$ uname -a
SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10
  

I'll fix that option order in libtool, but I don't see how it could have
caused a failed install for you, because we explicitly do
  ln -s -f A B || { rm -f B && ln -s A B; }

Please also note that this ln does not do the right thing with -f -s
when the target file already exists:



Hmm, reordering would be ugly because of the $LN_S abstraction.  Upon
reconsideration, I don't think it is that important to try to avoid some
inconsequential error message stemming from a setup which the default
GNU INSTALL file already advises not to use:

[...]
   On Solaris, don't put `/usr/ucb' early in your `PATH'.  This
directory contains several dysfunctional programs; working variants of
these programs are available in `/usr/bin'.  So, if you need `/usr/ucb'
in your `PATH', put it _after_ `/usr/bin'.
[...]

Not sure if OpenMPI copies this text somewhere, but if it doesn't, maybe
it should?

You didn't confirm whether your installation actually failed though.
Did it succeed?
  


I will take the advice about moving /usr/ucb to the end of my PATH - 
thanks for that.


I am having other issues on this platform that leave me uncertain about 
whether the install was successful or not.  The "make install" did run 
to completion, but despite adding $prefix/lib to my LD_LIBRARY_PATH, I 
don't seem to have a working build.  Keep in mind, however, that this is 
the same platform for which I just sent the "../libtool --config" output 
due to "make check" failing to locate libmpi.so.0.  So, I think I should 
wait for that to be resolved first.


Now that I think of it, I had best retry from scratch with /usr/ucb at 
the end of my PATH to see if that other problem goes away.


-Paul


Thanks,
Ralf
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] make install (libtool) failure on Solaris 10 (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

I agree w/ Ralph that
   ln -s -f A B || { rm -f B && ln -s A B; }
should have worked despite the error message from the failing "ln -s -f 
A B".

So, I don't think there was a real error here - sorry.

-Paul

Ralf Wildenhues wrote:

Hi Paul,

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 05:37:23AM CEST:
  

This has got to be the stupidest failure I have ever seen!

$ make install
[...]
make[3]: Entering directory
`/export/home/phargrov/openmpi-1.5rc5/BLD-gcc-vt/ompi'
test -z "/usr/local/pkg/ompi-1.5rc5/lib" || ../../config/install-sh
-c -d "/usr/local/pkg/ompi-1.5rc5/lib"
/bin/bash ../libtool   --mode=install ../../config/install-sh -c
libmpi.la '/usr/local/pkg/ompi-1.5rc5/lib'
libtool: install: ../../config/install-sh -c .libs/libmpi.so.0.0.2
/usr/local/pkg/ompi-1.5rc5/lib/libmpi.so.0.0.2
libtool: install: (cd /usr/local/pkg/ompi-1.5rc5/lib && { ln -s -f
libmpi.so.0.0.2 libmpi.so.0 || { rm -f libmpi.so.0 && ln -s
libmpi.so.0.0.2 libmpi.so.0; }; })
Usage: ln [-f] [-s] f1
  ln [-f] [-s] f1 f2
  ln [-f] [-s] f1 ... fn d1
[...]

This is due to an incomprehensibly stupid "ln" that cares about the
order of the "-s" and "-f" options:

$ rm -f b; touch a; ln -f -s a b
$ rm -f b; touch a; ln -s -f a b
Usage: ln [-f] [-s] f1
  ln [-f] [-s] f1 f2
  ln [-f] [-s] f1 ... fn d1

$ which ln
/usr/ucb/ln

$ uname -a
SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10



I'll fix that option order in libtool, but I don't see how it could have
caused a failed install for you, because we explicitly do
  ln -s -f A B || { rm -f B && ln -s A B; }

Please also note that this ln does not do the right thing with -f -s
when the target file already exists:

$ /usr/ucb/ln -f -s a b; echo $?
ln: b: File exists
1

Generally, having /usr/ucb early in $PATH on Solaris doesn't seem ideal,
the Autoconf manual describes several issues with tools in that
directory.

Cheers, and thanks for the report,
Ralf
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] Problem w/ documented SPARC/gcc flags (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

Rolf,

Thanks for looking into this issue.  Can you explain for me why V8+ is 
OK w/ the Sun C complier, but V9 is required w/ gcc?  I am guessing that 
one is an ABI flag and the other is a CPU flag, right?


-Paul

P.S.
The V8+ vs V9 ABI differences are described at 
http://developers.sun.com/solaris/articles/sparcv9abi.html


Rolf vandeVaart wrote:
 I have dug a little more into this.  I am now just planning to fix 
the README to match
the configure message.  In short, use CFLAGS="-mcpu=v9".  It turns out 
this change
was made in the configure code, but the README was never updated.  
This should

work properly for all cases.

Rolf

On 8/25/2010 6:53 PM, Paul H. Hargrove wrote:

In the message below I fouled up some cut-and-paste.
Please mentally replace

And have configured (again stopping after the Assembler ABI probe) 
with gcc-4.3.3 AND Rolf's flags
  CC=gcc-4.3.3 CXX=g++-4.3.3 CFLAGS=-mv8plus CC=gcc-4.3.3 
CXX=g++-4.3.3 CFLAGS=-mv8plus


with

And have configured (again stopping after the Assembler ABI probe) 
with gcc-4.3.3 AND Rolf's flags
  CC=gcc-4.3.3 CXX=g++-4.3.3  CFLAGS="-mv8plus -Wa,-xarch=v8plus" 
CXXFLAGS="-mv8plus -Wa,-xarch=v8plus"


-Paul



Paul H. Hargrove wrote:

Trying Rolf's suggestion, I configure 1.4.3rc1 with
  CFLAGS="-mv8plus -Wa,-xarch=v8plus" CXXFLAGS="-mv8plus 
-Wa,-xarch=v8plus"
I find that I get configure past the v8+/v9 Assembler ABI probe (but 
didn't wait for the full configure to run).


Another datapoint in favor of #2 is that I can successfully build 
1.4.3rc1 w/ gcc-4.3.3 when I configure with

   CC=gcc-4.3.3 CXX=g++-4.3.3 CFLAGS=-mv8plus CXXFLAGS=-mv8plus
And have configured (again stopping after the Assembler ABI probe) 
with gcc-4.3.3 AND Rolf's flags
   CC=gcc-4.3.3 CXX=g++-4.3.3 CFLAGS=-mv8plus CC=gcc-4.3.3 
CXX=g++-4.3.3 CFLAGS=-mv8plus


So, here is MY summary:

+ For gcc-4.3.3 README is providing correct information
+ For gcc-3.3.2 README is providing INcorrect information
+ For both gcc versions configure provides correct info on failure, 
but following it prevents using the V8+ ABI.


My suggestion fix:

+ Edit README and configure both to suggest "-mv8plus 
-Wa,-xarch=v8plus" as that should be correct for either compiler 
version.


-Paul

Rolf vandeVaart wrote:
Paul, is it possible for you to try one more thing.  Can you 
reconfigure with


CFLAGS="-mv8plus -Wa,-xarch=v8plus"

I think this will get past the configure test as the configure test 
is compiling a piece
of assembly, and for some reason, the -mv8plus is not finding its 
way to the assembler.


If that works, then we eliminate #2 on your list below, and have to 
decide between

#1 and #3.
Rolf

On 08/25/10 15:56, Paul H. Hargrove wrote:

In both 1.5rc5 and 1.4.3rc1, README says:
- Open MPI does not support the Sparc v8 CPU target, which is the
 default on Sun Solaris.  The v8plus (32 bit) or v9 (64 bit)
 targets must be used to build Open MPI on Solaris.  This can be
 done by including a flag in CFLAGS, CXXFLAGS, FFLAGS, and FCFLAGS,
 -xarch=v8plus for the Sun compilers, -mv8plus for GCC.

However, the -mv8plus flag DOES NOT work for me.
The following occurs for both 1.5rc5 and 1.4.3rc1:

$ uname -a
SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10

$ gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


$ [path_to]/configure --disable-mpi-f77 --disable-mpi-f90 
CFLAGS=-mv8plus CXXFLAGS=-mv8plus

[...]
*** Assembler
[...]
checking if have Sparc v8+/v9 support... no
configure: WARNING: Sparc v8 target is not supported in this 
release of Open MPI.

configure: WARNING: You must specify the target architecture v8plus
configure: WARNING: (cc: -xarch=v8plus, gcc: -mcpu=v9) for CFLAGS, 
CXXFLAGS,
configure: WARNING: FFLAGS, and FCFLAGS to compile Open MPI in 32 
bit mode on

configure: WARNING: Sparc processors
configure: error: Can not continue.


Following the recommendation from configure:
 $ [path_to]/configure --disable-mpi-f77 --disable-mpi-f90 
CFLAGS=-mcpu=v9 CXXFLAGS=-mcpu=v9

DOES work for both of the current RCs.

So, I see a few possibilities:

1) -mv8plus SHOULD work (as -xarch=v8plus appears to w/ Suc C 
5.10) but configure is unconditionally too strict.

OR
2) My gcc is older than other have tested and configure is 
mistakenly thinking the ABI is wrong.

OR
3) -mcpu=v9 is the proper incantation and README needs correction.

No matter which of the above is correct, I suspect REAME and 
configure need to give the user the same information.


-Paul

P.S.  I can provide temporary machine access if needed to resolve 
this.
P.P.S.  I am /still/ not finished testing all the platforms 
available to me ;-)




___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel






___
devel 

Re: [OMPI devel] "make check" (libtool?) failure on Solaris/SPARC (1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

Ralf Wildenhues wrote:

Hello Paul,

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 01:58:11AM CEST:
  

I have been able to configure and build both 1.5rc5 and 1.4.3rc1 on
Solaris 10 for SPARC, using Sun C 5.10.
I have also build 1.5rc5 w/ gcc-3.3.2 (and expect 1.4.3rc1 to build
w/ gcc as well, once I have time)

All 3 builds fail "make check" in a way that suggests to me that
libtool is not working correctly on this platform.



Can you send output of './libtool --config' for the platforms?

Thanks,
Ralf
  


Requested output is attached.

-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900


# Whether or not to build shared libraries.
build_libtool_libs=yes

# Whether or not to build static libraries.
build_old_libs=no

# A BSD- or MS-compatible name lister.
NM="/usr/ccs/bin/nm -p"

# Which release of libtool.m4 was used?
macro_version=2.2.6b
macro_revision=1.3017

# Assembler program.
AS=as

# DLL creation program.
DLLTOOL=dlltool

# Object dumper program.
OBJDUMP=false

# What type of objects to build.
pic_mode=default

# Whether or not to optimize for fast installation.
fast_install=needless

# The host system.
host_alias=
host=sparc-sun-solaris2.10
host_os=solaris2.10

# The build system.
build_alias=
build=sparc-sun-solaris2.10
build_os=solaris2.10

# A sed program that does not truncate output.
SED="/opt/csw/bin/gsed"

# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed="$SED -e 1s/^X//"

# A grep program that handles long lines.
GREP="/usr/sfw/bin/ggrep"

# An ERE matcher.
EGREP="/usr/sfw/bin/ggrep -E"

# A literal string matcher.
FGREP="/usr/sfw/bin/ggrep -F"

# Whether we need soft or hard links.
LN_S="ln -s"

# What is the maximum length of a command?
max_cmd_len=786240

# Object file suffix (normally "o").
objext=o

# Executable file suffix (normally "").
exeext=

# whether the shell understands "unset".
lt_unset=unset

# turn spaces into newlines.
SP2NL="tr \\040 \\012"

# turn newlines into spaces.
NL2SP="tr \\015\\012 \\040\\040"

# How to create reloadable object files.
reload_flag=" -r"
reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"

# Method to check whether dependent libraries are shared objects.
deplibs_check_method="pass_all"

# Command to use when deplibs_check_method == "file_magic".
file_magic_cmd="\$MAGIC_CMD"

# The archiver.
AR="ar"
AR_FLAGS="cru"

# A symbol stripping program.
STRIP="strip"

# Commands used to install an old-style archive.
RANLIB="ranlib"
old_postinstall_cmds="chmod 644 \$oldlib~\$RANLIB \$oldlib"
old_postuninstall_cmds=""

# A C compiler.
LTCC="gcc"

# LTCC compiler flags.
LTCFLAGS="-O3 -DNDEBUG -mcpu=v9 -finline-functions -fno-strict-aliasing "

# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe="sed -n -e 's/^.*[]\\([BDRT][BDRT]*\\)[   ][  
]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'"

# Transform the output of nm in a proper C declaration.
global_symbol_to_cdecl="sed -n -e 's/^T .* \\(.*\\)\$/extern int \\1();/p' -e 
's/^[BDRT]* .* \\(.*\\)\$/extern char \\1;/p'"

# Transform the output of nm in a C name address pair.
global_symbol_to_c_name_address="sed -n -e 's/^: \\([^ ]*\\) \$/  {\\\"\\1\\\", 
(void *) 0},/p' -e 's/^[BDRT]* \\([^ ]*\\) \\([^ ]*\\)\$/  {\"\\2\", (void *) 
\\&\\2},/p'"

# Transform the output of nm in a C name address pair when lib prefix is needed.
global_symbol_to_c_name_address_lib_prefix="sed -n -e 's/^: \\([^ ]*\\) \$/  
{\\\"\\1\\\", (void *) 0},/p' -e 's/^[BDRT]* \\([^ ]*\\) \\(lib[^ ]*\\)\$/  
{\"\\2\", (void *) \\&\\2},/p' -e 's/^[BDRT]* \\([^ ]*\\) \\([^ ]*\\)\$/  
{\"lib\\2\", (void *) \\&\\2},/p'"

# The name of the directory that contains temporary libtool files.
objdir=.libs

# Shell to use when invoking shell scripts.
SHELL="/bin/bash"

# An echo program that does not interpret backslashes.
ECHO="echo"

# Used to examine libraries when file_magic_cmd begins with "file".
MAGIC_CMD=file

# Must we lock files when doing compilation?
need_locks="no"

# Tool to manipulate archived DWARF debug symbol files on Mac OS X.
DSYMUTIL=""

# Tool to change global to local symbols on Mac OS X.
NMEDIT=""

# Tool to manipulate fat objects and archives on Mac OS X.
LIPO=""

# ldd/readelf like tool for Mach-O binaries on Mac OS X.
OTOOL=""

# ldd/readelf like tool for 64 bit Mach-O binaries on Mac OS X 10.4.
OTOOL64=""

# Old archive suffix (normally "a").
libext=a

# Shared library suffix (normally ".so").
shrext_cmds=".so"

# The commands to extract the exported symbol list from a shared archive.
extract_expsyms_cmds=""

# Variables whose values should be saved in libtool wrapper scripts and
# restored at link time.
variables_saved_for_relink="PATH LD_LIBRARY_PATH "

# Do we need the "lib" prefix for modules?
need_lib_prefix=no

# Do we need a version for libraries?
need_ve

Re: [OMPI devel] make install (libtool) failure on Solaris 10 (1.5rc5 and 1.4.3rc1)

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Aug 26, 2010 at 07:29:17AM CEST:
> * Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 05:37:23AM CEST:
> > libtool: install: (cd /usr/local/pkg/ompi-1.5rc5/lib && { ln -s -f
> > libmpi.so.0.0.2 libmpi.so.0 || { rm -f libmpi.so.0 && ln -s
> > libmpi.so.0.0.2 libmpi.so.0; }; })
> > Usage: ln [-f] [-s] f1
[...]

> > This is due to an incomprehensibly stupid "ln" that cares about the
> > order of the "-s" and "-f" options:
> > 
> > $ rm -f b; touch a; ln -f -s a b
> > $ rm -f b; touch a; ln -s -f a b
> > Usage: ln [-f] [-s] f1
> >   ln [-f] [-s] f1 f2
> >   ln [-f] [-s] f1 ... fn d1
> > 
> > $ which ln
> > /usr/ucb/ln
> > 
> > $ uname -a
> > SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10
> 
> I'll fix that option order in libtool, but I don't see how it could have
> caused a failed install for you, because we explicitly do
>   ln -s -f A B || { rm -f B && ln -s A B; }
> 
> Please also note that this ln does not do the right thing with -f -s
> when the target file already exists:

Hmm, reordering would be ugly because of the $LN_S abstraction.  Upon
reconsideration, I don't think it is that important to try to avoid some
inconsequential error message stemming from a setup which the default
GNU INSTALL file already advises not to use:

[...]
   On Solaris, don't put `/usr/ucb' early in your `PATH'.  This
directory contains several dysfunctional programs; working variants of
these programs are available in `/usr/bin'.  So, if you need `/usr/ucb'
in your `PATH', put it _after_ `/usr/bin'.
[...]

Not sure if OpenMPI copies this text somewhere, but if it doesn't, maybe
it should?

You didn't confirm whether your installation actually failed though.
Did it succeed?

Thanks,
Ralf

Re: [OMPI devel] 1.5rc5 - warnings from Sun C 5.10

[Rainer Keller]

Hello Paul,
thanks for testing so thoroughly.

On Wednesday 25 August 2010 02:40:22 Paul H. Hargrove wrote:
> In addition to the atomic.h and Anachronism warnings seen w/ 1.4.3rc1
> (http://www.open-mpi.org/community/lists/devel/2010/08/8322.php), I find
> some "new" warnings in 1.5rc5.
> 
> $ uname -a
> SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc
>
> $ cc -V
> cc: Sun C 5.10 SunOS_i386 2009/06/03
> usage: cc [ options] files. Use 'cc -flags' for details
Nice. I have installed the SunStudio Compiler Suite 12 update1 on a x86-64 
machine, aka:
cc: Sun C 5.10 Linux_i386 2009/06/03


Now, I do get some other unrelated errors already in the configure:

configure:18047: checking size of bool
configure:18052: CC -o conftest -O -DNDEBUGconftest.cpp  >&5
"/usr/include/stdlib.h", line 525: Error: "{" expected instead of "__asm".
"/usr/include/stdlib.h", line 525: Error: The function "__asm" must have a 
prototype.
"/usr/include/stdlib.h", line 958: Error: "at_quick_exit(void(*)())" is 
expected to return a value.

This is due to us enabling GNU-extensions, done through 
AC_USE_SYSTEM_EXTENSIONS and it's alias AC_GNU_SOURCE.

I'll forward this to Sun.



> Many instances of the following:
> 
> "../../../../openmpi-1.5rc5/orte/mca/ess/ess.h", line 61: warning:
> attribute "noreturn" may not be applied to variable, ignored
> "../../../../openmpi-1.5rc5/orte/mca/errmgr/errmgr.h", line 138:
> warning: attribute "noreturn" may not be applied to variable, ignored
> [Due to applying __opal_attribute_noreturn__ to a function pointer]
See the other mail.


> Single instances of the following:
> 
> "../../../../../openmpi-1.5rc5/opal/mca/crs/none/crs_none_module.c",
> line 136: warning: statement not reached

> "../../../../openmpi-1.5rc5/orte/mca/plm/base/plm_base_rsh_support.c",
> line 462: warning: implicit function declaration: rindex
Hmm, fixed in r23671


> "../../../../openmpi-1.5rc5/orte/mca/plm/base/plm_base_rsh_support.c",
> line 565: warning: improper pointer/integer combination: op "="
fixed by the above as well.

Best regards,
Rainer
-- 

 Dr.-Ing. Rainer Keller  http://www.hlrs.de/people/keller
 HLRS Tel: ++49 (0)711-685 6 5858
 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832
 70550 Stuttgartemail: kel...@hlrs.de 
 Germany AIM/Skype:rusraink

Re: [OMPI devel] 1.5rc5: attribute((noreturn)) and pointers to functions

[Rainer Keller]

Hi Paul,
having seen Your initial mail on Sun's support for noreturn (I have had some 
fun with their CC, see other mail, so I use g++), I implemented Your 
suggestion and tried with Sun's 12.1 compiler on Linux x86-64.

I will commit this later in the day (touching m4...)

Thanks,
Rainer

PS: Please note, that the commit won't fix v1.5, since it depends on changes 
applied in r22872, revamping the errmgr, which have not been moved over.



On Wednesday 25 August 2010 23:23:01 Paul H. Hargrove wrote:
> Building 1.5rc5 with xlc on linux/ppc I see many instances of the
> following warnings
> 
> "../../../../orte/mca/ess/ess.h", line 61.16: 1506-959 (W) The attribute
> "noreturn" is not a valid type attribute and is ignored.
> "../../../../orte/mca/errmgr/errmgr.h", line 134.16: 1506-959 (W) The
> attribute "noreturn" is not a valid type attribute and is ignored.
> 
> This is nearly the same as the Sun C 5.10 warning I reported in
> http://www.open-mpi.org/community/lists/devel/2010/08/8323.php
> 
> "../../../../openmpi-1.5rc5/orte/mca/ess/ess.h", line 61: warning:
> attribute "noreturn" may not be applied to variable, ignored
> "../../../../openmpi-1.5rc5/orte/mca/errmgr/errmgr.h", line 138:
> warning: attribute "noreturn" may not be applied to variable, ignored
> 
> This indicates a common cause and suggests a common solution:
> 
> In both cases the configure probe for compiler support for the
> "noreturn" attribute has passed.  However, in both cases the compiler is
> not happy applying this attribute to a pointer-to-function, (though gcc
> is apparently fine with this).  I believe that the solution to this is
> simply to add a "noreturn_funcptr" probe to
> opal/config/opal_check_attributes.m4, analogous to the format_funcptr
> probe and then define and use a __opal_attribute_noreturn_funcptr__ as
> appropriate.
> 
> -Paul

-- 

 Dr.-Ing. Rainer Keller  http://www.hlrs.de/people/keller
 HLRS Tel: ++49 (0)711-685 6 5858
 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832
 70550 Stuttgartemail: kel...@hlrs.de 
 Germany AIM/Skype:rusraink

[OMPI devel] 1.5rc5 over MX

[Scott Atchley]

Hi all,

Testing 1.5rc5 over MX with the same setup as 1.4.3rc1 (RHEL 5.4 and MX 1.2.12).

This version also dies during init due to the memory manager if I do not 
specify which pml to use. If I specify pml ob1 or pml cm, the tests start but 
die with segfaults:

   131072  320   166.86   749.15
[rain15:14939] *** Process received signal ***
[rain15:14939] Signal: Segmentation fault (11)
[rain15:14939] Signal code: Address not mapped (1)
[rain15:14939] Failing at address: 0x3b20

Again, configuring without the memory manager or setting 
OMPI_MCA_memory_ptmalloc2_disable=1 before calling mpirun work.

Similar latency issues with the BTl and not with the MTL.

Scott

[OMPI devel] 1/4/3rc1 over MX

[Scott Atchley]

Hi all,

I compiled 1.4.3rc1 with MX 1.2.12 on RHEL 5.4 (2.6.18-164.el5). It does not 
like the memory manager and MX. Compiling using --without-memory-manager works 
fine. The output below is form the default configure (i.e. 
--with-memory-manager).

Note, I still see unusual latencies for some tests when using the BTL such as 
reduce-scatter, allgather, etc. I do not see them with the MTL. An example of 
BTL latencies from reduce-scatter is:

  256 1000 7.01 7.01 7.01
  512 1000 7.56 7.56 7.56
 1024 1000 8.58 8.58 8.58
 2048 100010.3610.3610.36
 4096 100014.4914.4914.49
 8192 1000  5180.16  5180.57  5180.36
16384 100094.9694.9794.96
32768 1000  4676.30  4676.68  4676.49
65536  640  4625.85  4626.23  4626.04
   131072  320   243.43   243.46   243.45
   262144  160   425.56   425.66   425.61

Scott

% mpirun -hostfile hosts -np 2 ./IMB-MPI1.ompi-1.4.3rc1 pingpong
[rain16:22509] *** Process received signal ***
[rain16:22509] Signal: Segmentation fault (11)
[rain16:22509] Signal code: Address not mapped (1)
[rain16:22509] Failing at address: 0x2c0
[rain15:24145] *** Process received signal ***
[rain15:24145] Signal: Segmentation fault (11)
[rain15:24145] Signal code: Address not mapped (1)
[rain15:24145] Failing at address: 0x25a0
--
mpirun noticed that process rank 1 with PID 22509 on node rain16 exited on 
signal 11 (Segmentation fault).
--

gdb shows:

#0  0x003d084075c8 in ?? () from /lib64/libgcc_s.so.1
(gdb) bt
#0  0x003d084075c8 in ?? () from /lib64/libgcc_s.so.1
#1  0x003d0840882b in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
#2  0x003d060e5eb8 in backtrace () from /lib64/libc.so.6
#3  0x2af68e7a47de in opal_backtrace_buffer ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libopen-pal.so.0
#4  0x2af68e7a24ce in show_stackframe ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libopen-pal.so.0
#5  
#6  0x02c0 in ?? ()
#7  0x2af690520640 in mca_mpool_fake_release_memory ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/openmpi/mca_mpool_fake.so
#8  0x2af68e2f49ce in mca_mpool_base_mem_cb ()
   from /nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libmpi.so.0
#9  0x2af68e78347b in opal_mem_hooks_release_hook ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libopen-pal.so.0
#10 0x2af68e7a791f in opal_mem_free_ptmalloc2_munmap ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libopen-pal.so.0
#11 0x2af68e7ac2b1 in opal_memory_ptmalloc2_free_hook ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libopen-pal.so.0
#12 0x003d060727c1 in free () from /lib64/libc.so.6
#13 0x2af69197aaad in mx__rl_fini (rl=0xab5f928)
at ../../../libmyriexpress/userspace/../mx__request.c:102
#14 0x2af69196924d in mx_close_endpoint (endpoint=0xab5f820)
at ../../../libmyriexpress/userspace/../mx_close_endpoint.c:124
#15 0x2af69155e3dc in ompi_mtl_mx_finalize ()
   from 
/nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/openmpi/mca_mtl_mx.so
#16 0x2af68e2f87e0 in mca_pml_base_select ()
   from /nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libmpi.so.0
#17 0x2af68e2bcf40 in ompi_mpi_init ()
   from /nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libmpi.so.0
#18 0x2af68e2da2b1 in PMPI_Init_thread ()
   from /nfs/home/atchley/projects/openmpi-1.4.3rc1/build/rain/lib/libmpi.so.0
#19 0x00403359 in main ()


If I tell it to use BTLs only it changes to:

% mpirun -mca pml ob1 -hostfile hosts -np 2 ./IMB-MPI1.ompi-1.4.3rc1 pingpong
[rain16:22552] *** Process received signal ***
[rain15:24195] *** Process received signal ***
[rain15:24195] Signal: Segmentation fault (11)
[rain15:24195] Signal code: Address not mapped (1)
[rain15:24195] Failing at address: 0x290
[rain16:22552] Signal: Segmentation fault (11)
[rain16:22552] Signal code: Address not mapped (1)
[rain16:22552] Failing at address: 0x290
--
mpirun noticed that process rank 1 with PID 22552 on node rain16 exited on 
signal 11 (Segmentation fault).
--

gdb shows:

#0  0x003d084075c8 in ?? () from /lib64/libgcc_s.so.1
#1  0x003d0840882b in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
#2  0x003d060e5eb8 in backtrace () from /lib64/libc.so.6
#3  0x2b831

Re: [OMPI devel] Question on the members of ompi_crcp_bkmrk_pml_drain_message_ref_t and ompi_crcp_bkmrk_pml_traffic_message_ref_t

[Joshua Hursey]

Ananda,

So I think the comments are just misleading/wrong here. So messages are grouped 
by signature/envelope of the message. The 
ompi_crcp_bkmrk_pml_drain_message_ref_t and 
ompi_crcp_bkmrk_pml_traffic_message_ref_t data structures describe the envelope 
and each have a list of 'msg_contents' that point to the unique information for 
each message (e.g., buffer, request, status) of the type 
ompi_crcp_bkmrk_pml_message_content_ref_t.

So the 'drain_message' and 'traffic_message' datatypes use the various integers 
to count the number of done/active/posted 'message_content' datatypes stored in 
the list that they are responsible for. The internals of crcp_bkmrk_pml.c use 
these counter values to quickly look up what needs to be drained or waited on 
instead of iterating through the list of all messages every time.

This was a technique to reduce both the memory footprint of the implementation 
and improve performance slightly. It looks like the comments were not updated 
to match the change. Sorry about that. I'll file a ticket to update those 
comments in the trunk and branches so I don't forget.
  https://svn.open-mpi.org/trac/ompi/ticket/2550

I hope that helps a bit.

Best,
Josh

On Aug 26, 2010, at 1:59 AM,   
wrote:

> Josh
>  
> In the file ompi/mca/crcp/bkmrk/crcp_bkmrk_pml.h, I have a question on the 
> way few of the members of the following structures are defined:
> ompi_crcp_bkmrk_pml_drain_message_ref_t
> ompi_crcp_bkmrk_pml_traffic_message_ref_t
>  
> Under the definition of “ompi_crcp_bkmrk_pml_drain_message_ref_t”, based on 
> the comments following members are better declared as Boolean variables 
> however they are declared as integers. Is there any reason for not using 
> Boolean type?
>  
> /** Is this message complete WRT PML semantics?
>  * true = message done on this side (send or receive)
>  * false = message still in process (sending or receiving)
>  */
> int done;
>  
> /** Is the message actively being worked on?
>  * true = Message is !done, and is in the progress cycle
>  * false = Message is !done and is *not* in the progress cycle ( 
> [send/recv]_init requests)
>  */
> int active;
>  
> /** Has this message been posted?
>  * true = message was posted (Send or recv)
>  * false = message was not yet posted.
>  *   Used when trying to figure out which messages the drain protocol 
> needs to post, and
>  *   which message have already been posted for it.
>  */
> int already_posted;
>  
> I see that you have used bool type for similar members in 
> ompi_crcp_bkmrk_pml_message_content_ref_t.
>  
> Thanks
> Ananda
>  
> Ananda B Mudar, PMP
> Senior Technical Architect
> Wipro Technologies
> Please do not print this email unless it is absolutely necessary.
> 
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments.
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should 
> check this email and any attachments for the presence of viruses. The company 
> accepts no liability for any damage caused by any virus transmitted by this 
> email.
> 
> www.wipro.com
> 
> 


Joshua Hursey
Postdoctoral Research Associate
Oak Ridge National Laboratory
http://www.cs.indiana.edu/~jjhursey

Re: [OMPI devel] Problem w/ documented SPARC/gcc flags (1.5rc5 and 1.4.3rc1)

[Rolf vandeVaart]

 I have dug a little more into this.  I am now just planning to fix the 
README to match
the configure message.  In short, use CFLAGS="-mcpu=v9".  It turns out 
this change
was made in the configure code, but the README was never updated.  This 
should

work properly for all cases.

Rolf

On 8/25/2010 6:53 PM, Paul H. Hargrove wrote:

In the message below I fouled up some cut-and-paste.
Please mentally replace

And have configured (again stopping after the Assembler ABI probe) 
with gcc-4.3.3 AND Rolf's flags
  CC=gcc-4.3.3 CXX=g++-4.3.3 CFLAGS=-mv8plus CC=gcc-4.3.3 
CXX=g++-4.3.3 CFLAGS=-mv8plus


with

And have configured (again stopping after the Assembler ABI probe) 
with gcc-4.3.3 AND Rolf's flags
  CC=gcc-4.3.3 CXX=g++-4.3.3  CFLAGS="-mv8plus -Wa,-xarch=v8plus" 
CXXFLAGS="-mv8plus -Wa,-xarch=v8plus"


-Paul



Paul H. Hargrove wrote:

Trying Rolf's suggestion, I configure 1.4.3rc1 with
  CFLAGS="-mv8plus -Wa,-xarch=v8plus" CXXFLAGS="-mv8plus 
-Wa,-xarch=v8plus"
I find that I get configure past the v8+/v9 Assembler ABI probe (but 
didn't wait for the full configure to run).


Another datapoint in favor of #2 is that I can successfully build 
1.4.3rc1 w/ gcc-4.3.3 when I configure with

   CC=gcc-4.3.3 CXX=g++-4.3.3 CFLAGS=-mv8plus CXXFLAGS=-mv8plus
And have configured (again stopping after the Assembler ABI probe) 
with gcc-4.3.3 AND Rolf's flags
   CC=gcc-4.3.3 CXX=g++-4.3.3 CFLAGS=-mv8plus CC=gcc-4.3.3 
CXX=g++-4.3.3 CFLAGS=-mv8plus


So, here is MY summary:

+ For gcc-4.3.3 README is providing correct information
+ For gcc-3.3.2 README is providing INcorrect information
+ For both gcc versions configure provides correct info on failure, 
but following it prevents using the V8+ ABI.


My suggestion fix:

+ Edit README and configure both to suggest "-mv8plus 
-Wa,-xarch=v8plus" as that should be correct for either compiler 
version.


-Paul

Rolf vandeVaart wrote:
Paul, is it possible for you to try one more thing.  Can you 
reconfigure with


CFLAGS="-mv8plus -Wa,-xarch=v8plus"

I think this will get past the configure test as the configure test 
is compiling a piece
of assembly, and for some reason, the -mv8plus is not finding its 
way to the assembler.


If that works, then we eliminate #2 on your list below, and have to 
decide between

#1 and #3.
Rolf

On 08/25/10 15:56, Paul H. Hargrove wrote:

In both 1.5rc5 and 1.4.3rc1, README says:
- Open MPI does not support the Sparc v8 CPU target, which is the
 default on Sun Solaris.  The v8plus (32 bit) or v9 (64 bit)
 targets must be used to build Open MPI on Solaris.  This can be
 done by including a flag in CFLAGS, CXXFLAGS, FFLAGS, and FCFLAGS,
 -xarch=v8plus for the Sun compilers, -mv8plus for GCC.

However, the -mv8plus flag DOES NOT work for me.
The following occurs for both 1.5rc5 and 1.4.3rc1:

$ uname -a
SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10

$ gcc --version
gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


$ [path_to]/configure --disable-mpi-f77 --disable-mpi-f90 
CFLAGS=-mv8plus CXXFLAGS=-mv8plus

[...]
*** Assembler
[...]
checking if have Sparc v8+/v9 support... no
configure: WARNING: Sparc v8 target is not supported in this 
release of Open MPI.

configure: WARNING: You must specify the target architecture v8plus
configure: WARNING: (cc: -xarch=v8plus, gcc: -mcpu=v9) for CFLAGS, 
CXXFLAGS,
configure: WARNING: FFLAGS, and FCFLAGS to compile Open MPI in 32 
bit mode on

configure: WARNING: Sparc processors
configure: error: Can not continue.


Following the recommendation from configure:
 $ [path_to]/configure --disable-mpi-f77 --disable-mpi-f90 
CFLAGS=-mcpu=v9 CXXFLAGS=-mcpu=v9

DOES work for both of the current RCs.

So, I see a few possibilities:

1) -mv8plus SHOULD work (as -xarch=v8plus appears to w/ Suc C 5.10) 
but configure is unconditionally too strict.

OR
2) My gcc is older than other have tested and configure is 
mistakenly thinking the ABI is wrong.

OR
3) -mcpu=v9 is the proper incantation and README needs correction.

No matter which of the above is correct, I suspect REAME and 
configure need to give the user the same information.


-Paul

P.S.  I can provide temporary machine access if needed to resolve 
this.
P.P.S.  I am /still/ not finished testing all the platforms 
available to me ;-)




___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] nit-pick: typo in README (1.4.3rc1 and 1.5rc5)

[Joshua Hursey]

Well that's slightly embarrassing. Thanks for the catch. I filed CMRs to have 
this patch applied to the v1.4 and 1.5 branches before the next releases. 
Tickets below:
  https://svn.open-mpi.org/trac/ompi/ticket/2548
  https://svn.open-mpi.org/trac/ompi/ticket/2549

Thanks,
Josh

On Aug 25, 2010, at 5:48 PM, Paul H. Hargrove wrote:

> The following patch applies to both 1.4.3rc1 and 1.5rc5 to fix a typo in 
> the README:
> 
> --- README.orig2010-08-25 14:45:09.0 -0700
> +++ README 2010-08-25 14:45:20.0 -0700
> @@ -69,7 +69,7 @@
> - Asynchronous, transparent checkpoint/restart support
>   - Fully coordinated checkpoint/restart coordination component
>   - Support for the following checkpoint/restart services:
> -- blcr: Berkley Lab's Checkpoint/Restart
> +- blcr: Berkeley Lab's Checkpoint/Restart
> - self: Application level callbacks
>   - Support for the following interconnects:
> - tcp
> 
> 
> 
> -Paul
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 


Joshua Hursey
Postdoctoral Research Associate
Oak Ridge National Laboratory
http://www.cs.indiana.edu/~jjhursey

Re: [OMPI devel] Checkpoint/restart question

[Joshua Hursey]

I have not played with the Condor checkpoint/restart library in quite some 
time. Supporting it should be fairly straight forward though (though the devil 
is always in the details with such things).

In Open MPI, all of the code to support checkpoint/restart services like BLCR 
or condor is part of a framework component in OPAL called CRS (for 
Checkpoint/Restart Service). To support a new checkpointer you will need to 
develop a new component under opal/mca/crs/. If you are (or someone you know 
is) interested in doing the development, you should be able to use the BLCR 
module to help guide you through the details.

This integration would allow you to use all of the Open MPI's current C/R 
infrastructure just with the Condor C/R library capturing the per process 
checkpoints. Storage and coordination is handled in other frameworks in the 
Open MPI environment so you should not need to worry about that at this level.

If you have any questions let me know and I can try to help you navigate the 
code base.

-- Josh

On Aug 25, 2010, at 7:36 PM, Tomas Oppelstrup wrote:

> Hi,
> I have a question about checkpoint-restart operation with opem-mpi. I
> hope this is an apropriate forum for my question.
> 
> I do not have access to recopmile the kernel or load kernel modules,
> so I would like to use the condor checkpoint-restart library. Can
> that me made to work with openmpi's checkpoint-restart
> infrastructure?
> 
> The condor library, upon recept of a signal or calling its checkpoint
> function from within the program, generates a file containing the
> complete (as complete as possible) state of the process, including
> the state of libraries, e.g. openmpi. On restart, the process
> image/state is loaded into memory and execution is resumed at the
> checkpoint location.
> 
> On restart, I assume that some information in the mpi-state may need
> to be reinitalized, since e.g. the names of the hosts of the
> mpi-process, and pids of possible support processes will have
> changed.
> 
> Is this tricky to fix (that code must somehow be there for the BLCR
> compatibility)?
> 
> Perhaps it can be achieved by (in violation of the mpi-standard)
> calling MPI_Finalize before the checkpoint, and MPI_Init after
> restart? This seems like a conceptually appealing solution, but may
> not be allowed nor to the correct thing in openmpi?!
> 
>  Thanks for any ideas/help/pointers to more information!
> 
> Tomas
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 


Joshua Hursey
Postdoctoral Research Associate
Oak Ridge National Laboratory
http://www.cs.indiana.edu/~jjhursey

Re: [OMPI devel] 1.5rc5: warning from gcc-4.0.1 on Mac OS 10.4.11 (x86 and ppc)

[Rainer Keller]

Hi Paul,
thanks for the exhaustive testing.

This is due to Mac OS not (yet) including the const in:
   int pthread_attr_getscope(const pthread_attr_t *attr, int *scope);
just verified: MacOS X 10.5.8 does contain the const.

nptl/glibc does contain it in the headers (but not in the man-page).

Best regards,
Rainer


On Wednesday 25 August 2010 06:44:01 Paul H. Hargrove wrote:
> I get a warning building 1.5rc5 that appears unique to this Mac OS version.
> It does NOT occur with
>   Mac OS 10.5.8 for x86
>   Mac OS 10.6.1 for x86
>   Mac OS 10.5.8 for ppc
> Nor does this occur with Open MPI 1.4.3rc1.
> 
> $ uname -a
> Darwin irun.lbl.gov 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10
> 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
> 
> $ sw_vers
> ProductName:Mac OS X
> ProductVersion: 10.4.11
> BuildVersion:   8S2167
> 
> $ gcc --version
> i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ [path_to]/openmpi-1.5rc5/configure
> [...]
> 
> $ make
> [...]
>   CC libvt_mt_la-vt_pthreadwrap.lo
> ../../../../../../ompi/contrib/vt/vt/vtlib/vt_pthreadwrap.c: In function
> 'VT_pthread_attr_getscope__':
> ../../../../../../ompi/contrib/vt/vt/vtlib/vt_pthreadwrap.c:365:
> warning: passing argument 1 of 'pthread_attr_getscope' discards
> qualifiers from pointer target type
> [...]
> 
> 
> 
> Same for the equivalent ppc platform:
> 
> $ uname -a; echo; sw_vers; echo; gcc --version
> Darwin iwalk.lbl.gov 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
> 
> ProductName:Mac OS X
> ProductVersion: 10.4.11
> BuildVersion:   8S165
> 
> powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
> 5341)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> -Paul

-- 

 Dr.-Ing. Rainer Keller  http://www.hlrs.de/people/keller
 HLRS Tel: ++49 (0)711-685 6 5858
 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832
 70550 Stuttgartemail: kel...@hlrs.de 
 Germany AIM/Skype:rusraink

Re: [OMPI devel] 1.5rc5: opal_path_nfs test failure on GPFS filesystem

[Nysal Jan]

Thanks for the report. Fixed in r23669 -
https://svn.open-mpi.org/trac/ompi/changeset/23669
I will file a CMR to move this to 1.5 branch

--Nysal

On Wed, Aug 25, 2010 at 11:55 AM, Paul H. Hargrove wrote:

> Testing 1.5rc5 on Linux/PPC64 I get a test failure in "make check" that
> probably relates to the GPFS filesystems used on this machine.  Not sure if
> this is a serious error or just an annoyance:
>
> $  cat /etc/SuSE-release
> SUSE Linux Enterprise Server 10 (ppc)
> VERSION = 10
> PATCHLEVEL = 3
>
> $ uname -a
> Linux login2 2.6.16.60-0.67.1-ppc64 #1 SMP Thu Aug 5 10:54:46 UTC 2010
> ppc64 ppc64 ppc64 GNU/Linux
>
> $ /lib64/libc.so.6
> GNU C Library stable release version 2.4 (20090904), by Roland McGrath et
> al.
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Configured for ppc64-suse-linux.
> Compiled by GNU CC version 4.1.2 20070115 (SUSE Linux).
> Compiled on a Linux 2.6.16 system on 2009-09-04.
> Available extensions:
>   crypt add-on version 2.1 by Michael Glad and others
>   GNU Libidn by Simon Josefsson
>   GNU libio by Per Bothner
>   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
>   Native POSIX Threads Library by Ulrich Drepper et al
>   BIND-8.2.3-T5B
> Thread-local storage support included.
> For bug reporting instructions, please see:
> .
>
> $ gcc -m64 --version
> gcc (GCC) 4.1.2 20070115 (SUSE Linux)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ mount | grep gpfs
> /dev/surveyor_software on /gpfs/software type gpfs
> (rw,mtime,dev=surveyor_software,autostart)
> /dev/surveyor_home on /gpfs/home type gpfs
> (rw,mtime,dev=surveyor_home,autostart)
>
> $ [path_to]/openmpi-1.5rc5/configure CC='gcc -m64' CXX='g++ -m64'
> F77='gfortran -m64' FC='gfortran -m64'
> [...]
>
> $ make
> [...]
>
> $ make check
> [...]
> gmake[3]: Entering directory
> `/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-64/test/util'
>  CC opal_path_nfs.o
>  CCLD   opal_path_nfs
> gmake[3]: Leaving directory
> `/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-64/test/util'
> gmake  check-TESTS
> gmake[3]: Entering directory
> `/gpfs/home/hargrove/tmp/openmpi-1.5rc5/BLD-64/test/util'
> Failure : Mismatch: input "/gpfs/software", expected:0 got:1
>
> Failure : Mismatch: input "/gpfs/home", expected:0 got:1
>
> SUPPORT: OMPI Test failed: opal_path_nfs() (2 of 17 failed)
> FAIL: opal_path_nfs
> 
> 1 of 1 test failed
> Please report to http://www.open-mpi.org/community/help/
> 
> [...]
>
>
>
> Same error occurs when configure is run with no argument (yielding an ILP32
> build).
>
> This test does not exist in 1.4.3rc1.
>
> -Paul
>
> --
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

Re: [OMPI devel] delivering SIGUSR2 to an ompi process

[Sylvain Jeaugey]

Steve,

This is indeed strange. The mechanism you describe works for me.

Here is my simple test :

-- mpi-sig.c --
#include "mpi.h"
#include 
#include 

void warn(int sig) {
printf("Got signal %d\n", sig);
}

int main (int argc, char ** argv) {
signal(SIGUSR2, warn);
MPI_Init(&argc,&argv);
while (1);
MPI_Finalize();
return 0;
}
---

Whenever I do a kill -SIGUSR2 on it, I get the message "Got signal 12" 
(the handler gets called).


If I remove the call to signal() I get the same message you get :

--
mpirun noticed that process rank 0 with PID 25067 on node bullx1 exited on 
signal 12 (User defined signal 2).
--

Maybe you should ensure that this simple test works, then figure out why 
it is different from yours.


Sylvain

On Wed, 25 Aug 2010, Steve Wise wrote:


On 08/25/2010 12:43 PM, Ralph Castain wrote:

On Aug 25, 2010, at 11:26 AM, Steve Wise wrote:



On 08/25/2010 11:33 AM, Ralph Castain wrote:

We don't use it - mpirun traps it and then propagates it by default to 
all remote procs.





So I should send the signal to the mpirun process?


Yes - however, note that it will be propagated to ALL processes in the job.

If you want to only get the signal in one proc, you can just do a "kill" to 
that specific process on its node. We don't trap signals on the application 
procs themselves, so your proc can do whatever it wants with it.






Something is funny then.  When I send SIGUSR2 to the process itself -or- to 
the mpirun proc, it just kills the process and doesn't get to my sig handler. 
And my same library works when I run the job using mvapich2.


I'll keep digging.

Thanks!

Steve.



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] Question on the members of ompi_crcp_bkmrk_pml_drain_message_ref_t and ompi_crcp_bkmrk_pml_traffic_message_ref_t

[ananda.mudar]

Josh



In the file ompi/mca/crcp/bkmrk/crcp_bkmrk_pml.h, I have a question on
the way few of the members of the following structures are defined:

ompi_crcp_bkmrk_pml_drain_message_ref_t

ompi_crcp_bkmrk_pml_traffic_message_ref_t



Under the definition of "ompi_crcp_bkmrk_pml_drain_message_ref_t", based
on the comments following members are better declared as Boolean
variables however they are declared as integers. Is there any reason for
not using Boolean type?



/** Is this message complete WRT PML semantics?

 * true = message done on this side (send or receive)

 * false = message still in process (sending or receiving)

 */

int done;



/** Is the message actively being worked on?

 * true = Message is !done, and is in the progress cycle

 * false = Message is !done and is *not* in the progress cycle (
[send/recv]_init requests)

 */

int active;



/** Has this message been posted?

 * true = message was posted (Send or recv)

 * false = message was not yet posted.

 *   Used when trying to figure out which messages the drain
protocol needs to post, and

 *   which message have already been posted for it.

 */

int already_posted;



I see that you have used bool type for similar members in
ompi_crcp_bkmrk_pml_message_content_ref_t.



Thanks

Ananda



Ananda B Mudar, PMP

Senior Technical Architect

Wipro Technologies


Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com

Re: [OMPI devel] make install (libtool) failure on Solaris 10 (1.5rc5 and 1.4.3rc1)

[Ralf Wildenhues]

Hi Paul,

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 05:37:23AM CEST:
> This has got to be the stupidest failure I have ever seen!
> 
> $ make install
> [...]
> make[3]: Entering directory
> `/export/home/phargrov/openmpi-1.5rc5/BLD-gcc-vt/ompi'
> test -z "/usr/local/pkg/ompi-1.5rc5/lib" || ../../config/install-sh
> -c -d "/usr/local/pkg/ompi-1.5rc5/lib"
> /bin/bash ../libtool   --mode=install ../../config/install-sh -c
> libmpi.la '/usr/local/pkg/ompi-1.5rc5/lib'
> libtool: install: ../../config/install-sh -c .libs/libmpi.so.0.0.2
> /usr/local/pkg/ompi-1.5rc5/lib/libmpi.so.0.0.2
> libtool: install: (cd /usr/local/pkg/ompi-1.5rc5/lib && { ln -s -f
> libmpi.so.0.0.2 libmpi.so.0 || { rm -f libmpi.so.0 && ln -s
> libmpi.so.0.0.2 libmpi.so.0; }; })
> Usage: ln [-f] [-s] f1
>   ln [-f] [-s] f1 f2
>   ln [-f] [-s] f1 ... fn d1
> [...]
> 
> This is due to an incomprehensibly stupid "ln" that cares about the
> order of the "-s" and "-f" options:
> 
> $ rm -f b; touch a; ln -f -s a b
> $ rm -f b; touch a; ln -s -f a b
> Usage: ln [-f] [-s] f1
>   ln [-f] [-s] f1 f2
>   ln [-f] [-s] f1 ... fn d1
> 
> $ which ln
> /usr/ucb/ln
> 
> $ uname -a
> SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10

I'll fix that option order in libtool, but I don't see how it could have
caused a failed install for you, because we explicitly do
  ln -s -f A B || { rm -f B && ln -s A B; }

Please also note that this ln does not do the right thing with -f -s
when the target file already exists:

$ /usr/ucb/ln -f -s a b; echo $?
ln: b: File exists
1

Generally, having /usr/ucb early in $PATH on Solaris doesn't seem ideal,
the Autoconf manual describes several issues with tools in that
directory.

Cheers, and thanks for the report,
Ralf

Re: [OMPI devel] "make check" (libtool?) failure on Solaris/SPARC (1.5rc5 and 1.4.3rc1)

[Ralf Wildenhues]

Hello Paul,

* Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 01:58:11AM CEST:
> I have been able to configure and build both 1.5rc5 and 1.4.3rc1 on
> Solaris 10 for SPARC, using Sun C 5.10.
> I have also build 1.5rc5 w/ gcc-3.3.2 (and expect 1.4.3rc1 to build
> w/ gcc as well, once I have time)
> 
> All 3 builds fail "make check" in a way that suggests to me that
> libtool is not working correctly on this platform.

Can you send output of './libtool --config' for the platforms?

Thanks,
Ralf

[OMPI devel] 1.5rc5: VT integration "issue" on Solaris/SPARC

[Paul H. Hargrove]

I've encountered an interesting situation on Solaris/SPARC where Open 
MPI defaults to CC=gcc but the contrib'ed VampirTrace is defaulting to 
CC=cc.  Additionally, Open MPI on SPARC requires CFLAGS be set to get a 
non-default ABI from the compiler.  This leads to two different failure 
modes for me...


Platform:

$ uname -a; echo; cc -V; echo; gcc --version
SunOS lem.lbl.gov 5.10 s10_69 sun4u sparc SUNW,Ultra-5_10

cc: Sun C 5.10 SunOS_sparc 2009/06/03
usage: cc [ options] files.  Use 'cc -flags' for details

gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


As detailed elsewhere 
(http://www.open-mpi.org/community/lists/devel/2010/08/8365.php) my 
gcc-3.3.2 will work with either of the following:

   CFLAGS="-mv8plus -Wa,-xarch=v8plus"
or
   CFLAGS=-mcpu=v9
Where and CXXFLAGS, FFLAGS and FCFLAGS are set to match.

Starting with the first option...

$ [path_to]/openmpi-1.5rc5/configure --disable-mpi-f90 CFLAGS='-mv8plus 
-Wa,-xarch=v8plus' CXXFLAGS='-mv8plus -Wa,-xarch=v8plus' 
FFLAGS='-mv8plus -Wa,-xarch=v8plus'

[...]
--- vt (m4 configuration macro)
configure: OMPI configuring in ompi/contrib/vt/vt
configure: running /bin/bash 
'../../../../../ompi/contrib/vt/vt/configure' --disable-option-checking 
--with-openmpi-inside '--disable-mpi-f90' 'CFLAGS=-mv8plus 
-Wa,-xarch=v8plus' 'CXXFLAGS=-mv8plus -Wa,-xarch=v8plus' 
'FFLAGS=-mv8plus -Wa,-xarch=v8plus'  --cache-file=/dev/null 
--srcdir=../../../../../ompi/contrib/vt/vt --disable-option-checking
checking for a BSD-compatible install... 
../../../../../ompi/contrib/vt/vt/config/install-sh -c

checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... 
../../../../../ompi/contrib/vt/vt/config/install-sh -c -d

checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for platform... sun
checking for options file... 
../../../../../ompi/contrib/vt/vt/config/defaults/sun
configure: loading options from 
'../../../../../ompi/contrib/vt/vt/config/defaults/sun'

CC="cc"
CXX="CC"
F77="f77"
FC="f95"
CFLAGS="-xO3"
CXXFLAGS="-xO3"
FFLAGS="-xO3"
FCFLAGS="-xO3"
OPENMP_CFLAGS="-xopenmp -xO3 -D_REENTRANT"
PTHREAD_CFLAGS="-D_REENTRANT"
PTHREAD_LIBS="-lpthread"
enable_memtrace="no"
enable_cpuidtrace="no"
configure: builddir: 
/export/home/phargrov/openmpi-1.5rc5/BLD-gcc-vt2/ompi/contrib/vt/vt

configure: srcdir: /export/home/phargrov/openmpi-1.5rc5/ompi/contrib/vt/vt
configure: detected VPATH build
checking if build filesystem is case sensitive... yes
checking for gcc... cc
checking whether the C compiler works... no
configure: error: in 
`/export/home/phargrov/openmpi-1.5rc5/BLD-gcc-vt2/ompi/contrib/vt/vt':

configure: error: C compiler cannot create executables
See `config.log' for more details.
configure: /bin/bash '../../../../../ompi/contrib/vt/vt/configure' 
*failed* for ompi/contrib/vt/vt

checking if contributed component vt can compile... no
[...]

The VT configure script has tried to us CC=cc and CFLAGS='-mv8plus 
-Wa,-xarch=v8plus', with the unsurprising result:

 checking whether the C compiler works... no
So, VT has been disabled.



Now the second CFLAGS option and corresponding failure mode:

$ [path_to]/openmpi-1.5rc5/configure --disable-mpi-f90 CFLAGS=-mcpu=v9 
CXXFLAGS=-mcpu=v9 FFLAGS=-mcpu=v9

[...]
--- vt (m4 configuration macro)
configure: OMPI configuring in ompi/contrib/vt/vt
configure: running /bin/bash 
'../../../../../ompi/contrib/vt/vt/configure' --disable-option-checking 
--with-openmpi-inside '--disable-mpi-f90' 'CFLAGS=-mcpu=v9' 
'CXXFLAGS=-mcpu=v9' 'FFLAGS=-mcpu=v9'  --cache-file=/dev/null 
--srcdir=../../../../../ompi/contrib/vt/vt --disable-option-checking
checking for a BSD-compatible install... 
../../../../../ompi/contrib/vt/vt/config/install-sh -c

checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... 
../../../../../ompi/contrib/vt/vt/config/install-sh -c -d

checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for platform... sun
checking for options file... 
../../../../../ompi/contrib/vt/vt/config/defaults/sun
configure: loading options from 
'../../../../../ompi/contrib/vt/vt/config/defaults/sun'

CC="cc"
CXX="CC"
F77="f77"
FC="f95"
CFLAGS="-xO3"
CXXFLAGS="-xO3"
FFLAGS="-xO3"
FCFLAGS="-xO3"
OPENMP_CFLAGS="-xopenmp -xO3 -D_REENTRANT"
PTHREAD_CFLAGS="-D_REENTRANT"
PTHREAD_LIBS="-lpthread"
enable_memtrace="no"
enable_cpuidtrace="no"
configure: builddir: 
/export/home/phargrov/openmpi-1.5rc5/BLD-gcc-vt/ompi/contrib/vt/vt

configure: srcdir: /export/home/phargrov/ope