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/debug
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, b
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 ge
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:
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:
* 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
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
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 i
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
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.
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
libm
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
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/so
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
* 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
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.
>
> $ unam
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: Plea
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 1
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 te
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' t
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/2
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,
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 o
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).
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
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) {
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"
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" || .
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)
>
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
30 matches
Mail list logo
