Thanks Tim!

On Jul 22, 2005, at 6:42 PM, Timothy B. Prins wrote:

Problem 2 should be fixed in the trunk. We now detect if the proper
version of bproc is available, and we will abort configure if the proper
version is not available and --with-bproc is passed.

To disable bproc entirely, simply pass --without-bproc or --with-bproc=no
to configure (this functionality was previously broken).

The current bproc modules support LANL bproc >=3.2.0. They do not
currently run on any version of Scyld or older LANL bproc. If anyone is
curious, we detect the bproc version by looking for sys/bproc_common.h,
which is only present in LANL bproc v 3.2.0 and greater. By happy
coincidence, v3.2.0 is the exact version where all the features we use are
first available.

Sorry, but this change should require an autogen/configure....

Tim

There appear to be 2 bproc problems in the tree right now:

1. I mailed Tim Prins / Greg Watson about one of them already (trying
to compile bproc on systems that don't have bproc -- perhaps related to
the .ompi_unignore from last night?).

2. The second was noticed by Joel Krauska from Cisco (he'll probably be
on this list shortly).  Here's a mail he sent to me last night:

I haven't done the due diligence to attempt to disable the bproc stuff
-- it just appears to not agree with my system and it's in the stock
"make"..   I will later read the documentation, but it looks like

ompi/orte/mca/pls/bproc_seed/pls_bproc_seed.c:446
    rc = bproc_vrfork(num_nodes, node_list, daemon_pids);

conflicts with my scyld system's
/usr/include/sys/bproc.h
        int  bproc_vrfork     (int *nodes, int nnodes);

Right now, I think we're just checking for bproc.h to determine if the
system has bproc -- we're not doing anything to figure out *which*
bproc you have (LANL vs. Scyld).

Does anyone have any Scyld machines lying around?  The prototype for
vrfork() is one indicator, but not the easiest to test fork -- are they
any other telltale #define's or such that we can use for testing in
configure?

--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/

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


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


--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/

Reply via email to