2004-07-01 14:49:54 +00:00
|
|
|
/*
|
2005-11-05 19:57:48 +00:00
|
|
|
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2006-08-23 03:32:36 +00:00
|
|
|
* Copyright (c) 2004-2006 The University of Tennessee and The University
|
2005-11-05 19:57:48 +00:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2004-11-28 20:09:25 +00:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
* University of Stuttgart. All rights reserved.
|
2005-03-24 12:43:37 +00:00
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
2004-11-22 01:38:40 +00:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
2004-07-01 14:49:54 +00:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
2005-03-18 03:43:59 +00:00
|
|
|
#include "orte_config.h"
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "orte/orte_constants.h"
|
2004-07-01 14:49:54 +00:00
|
|
|
|
|
|
|
#include <stdio.h>
|
2004-11-05 07:52:30 +00:00
|
|
|
#include <string.h>
|
2004-07-01 14:49:54 +00:00
|
|
|
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "orte/runtime/runtime.h"
|
2005-07-03 23:31:27 +00:00
|
|
|
#include "opal/util/output.h"
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "orte/util/proc_info.h"
|
2005-07-04 00:13:44 +00:00
|
|
|
#include "opal/util/argv.h"
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "opal/mca/mca.h"
|
|
|
|
#include "opal/mca/base/base.h"
|
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
|
|
|
#include "orte/mca/ns/ns.h"
|
|
|
|
#include "orte/mca/oob/oob.h"
|
|
|
|
#include "orte/mca/oob/base/base.h"
|
2004-07-01 14:49:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
OBJ_CLASS_INSTANCE(
|
2004-08-02 21:24:00 +00:00
|
|
|
mca_oob_t,
|
2005-07-03 16:22:16 +00:00
|
|
|
opal_list_item_t,
|
2004-07-01 14:49:54 +00:00
|
|
|
NULL,
|
|
|
|
NULL
|
|
|
|
);
|
2004-08-18 15:51:40 +00:00
|
|
|
|
2004-08-02 00:24:22 +00:00
|
|
|
OBJ_CLASS_INSTANCE(
|
|
|
|
mca_oob_base_info_t,
|
2005-07-03 16:22:16 +00:00
|
|
|
opal_list_item_t,
|
2004-08-02 00:24:22 +00:00
|
|
|
NULL,
|
|
|
|
NULL
|
|
|
|
);
|
2004-07-01 14:49:54 +00:00
|
|
|
|
2004-08-16 19:39:54 +00:00
|
|
|
/**
|
|
|
|
* Parse contact info string into process name and list of uri strings.
|
|
|
|
*/
|
|
|
|
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
int mca_oob_parse_contact_info(
|
|
|
|
const char* contact_info,
|
2005-03-14 20:57:21 +00:00
|
|
|
orte_process_name_t* name,
|
2004-08-16 19:39:54 +00:00
|
|
|
char*** uri)
|
|
|
|
{
|
2005-03-14 20:57:21 +00:00
|
|
|
orte_process_name_t* proc_name;
|
2005-03-18 03:43:59 +00:00
|
|
|
int rc;
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
|
2004-08-16 19:39:54 +00:00
|
|
|
/* parse the process name */
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
char* cinfo = strdup(contact_info);
|
2004-09-14 17:00:48 +00:00
|
|
|
char* ptr = strchr(cinfo, ';');
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
if(NULL == ptr) {
|
2005-03-18 03:43:59 +00:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_BAD_PARAM);
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
free(cinfo);
|
2005-03-18 03:43:59 +00:00
|
|
|
return ORTE_ERR_BAD_PARAM;
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
}
|
2004-08-16 19:39:54 +00:00
|
|
|
*ptr = '\0';
|
|
|
|
ptr++;
|
2005-03-18 03:43:59 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_ns.convert_string_to_process_name(&proc_name, cinfo))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
free(cinfo);
|
|
|
|
return rc;
|
2005-03-14 20:57:21 +00:00
|
|
|
}
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
*name = *proc_name;
|
|
|
|
free(proc_name);
|
2004-08-16 19:39:54 +00:00
|
|
|
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
if (NULL != uri) {
|
|
|
|
/* parse the remainder of the string into an array of uris */
|
2005-07-04 00:13:44 +00:00
|
|
|
*uri = opal_argv_split(ptr, ';');
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
}
|
|
|
|
free(cinfo);
|
2005-03-18 03:43:59 +00:00
|
|
|
return ORTE_SUCCESS;
|
2004-08-16 19:39:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-07-01 14:49:54 +00:00
|
|
|
/**
|
|
|
|
* Function for selecting one module from all those that are
|
|
|
|
* available.
|
|
|
|
*
|
|
|
|
* Call the init function on all available modules.
|
|
|
|
*/
|
2005-03-14 20:57:21 +00:00
|
|
|
int mca_oob_base_init(void)
|
2004-07-01 14:49:54 +00:00
|
|
|
{
|
2005-07-03 16:22:16 +00:00
|
|
|
opal_list_item_t *item;
|
2004-08-02 00:24:22 +00:00
|
|
|
mca_base_component_list_item_t *cli;
|
2004-07-01 14:49:54 +00:00
|
|
|
mca_oob_base_component_t *component;
|
2004-08-02 21:24:00 +00:00
|
|
|
mca_oob_t *module;
|
2004-08-28 01:15:19 +00:00
|
|
|
mca_oob_t *s_module = NULL;
|
|
|
|
int s_priority = -1;
|
2004-07-01 14:49:54 +00:00
|
|
|
|
2005-07-04 00:13:44 +00:00
|
|
|
char** include = opal_argv_split(mca_oob_base_include, ',');
|
|
|
|
char** exclude = opal_argv_split(mca_oob_base_exclude, ',');
|
2004-08-18 15:51:40 +00:00
|
|
|
|
2004-07-01 14:49:54 +00:00
|
|
|
/* Traverse the list of available modules; call their init functions. */
|
2005-07-03 16:22:16 +00:00
|
|
|
for (item = opal_list_get_first(&mca_oob_base_components);
|
|
|
|
item != opal_list_get_end(&mca_oob_base_components);
|
|
|
|
item = opal_list_get_next(item)) {
|
2004-08-02 00:24:22 +00:00
|
|
|
mca_oob_base_info_t *inited;
|
2004-07-01 14:49:54 +00:00
|
|
|
|
2004-08-02 00:24:22 +00:00
|
|
|
cli = (mca_base_component_list_item_t *) item;
|
|
|
|
component = (mca_oob_base_component_t *) cli->cli_component;
|
2004-07-01 14:49:54 +00:00
|
|
|
|
2004-08-18 15:51:40 +00:00
|
|
|
/* if there is an include list - item must be in the list to be included */
|
|
|
|
if ( NULL != include ) {
|
|
|
|
char** argv = include;
|
|
|
|
bool found = false;
|
|
|
|
while(argv && *argv) {
|
|
|
|
if(strcmp(component->oob_base.mca_component_name,*argv) == 0) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
argv++;
|
|
|
|
}
|
|
|
|
if(found == false) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* otherwise - check the exclude list to see if this item has been specifically excluded */
|
|
|
|
} else if ( NULL != exclude ) {
|
|
|
|
char** argv = exclude;
|
|
|
|
bool found = false;
|
|
|
|
while(argv && *argv) {
|
|
|
|
if(strcmp(component->oob_base.mca_component_name,*argv) == 0) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
argv++;
|
|
|
|
}
|
|
|
|
if(found == true) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-07-01 14:49:54 +00:00
|
|
|
if (NULL == component->oob_init) {
|
2005-07-03 23:31:27 +00:00
|
|
|
opal_output_verbose(10, mca_oob_base_output, "mca_oob_base_init: no init function; ignoring component");
|
2004-07-01 14:49:54 +00:00
|
|
|
} else {
|
2004-08-28 01:15:19 +00:00
|
|
|
int priority = -1;
|
2005-03-14 20:57:21 +00:00
|
|
|
module = component->oob_init(&priority);
|
2004-08-28 01:15:19 +00:00
|
|
|
if (NULL != module) {
|
|
|
|
inited = OBJ_NEW(mca_oob_base_info_t);
|
|
|
|
inited->oob_component = component;
|
|
|
|
inited->oob_module = module;
|
2005-07-03 16:22:16 +00:00
|
|
|
opal_list_append(&mca_oob_base_modules, &inited->super);
|
2004-08-28 01:15:19 +00:00
|
|
|
|
|
|
|
/* setup highest priority oob channel */
|
|
|
|
if(priority > s_priority) {
|
|
|
|
s_priority = priority;
|
|
|
|
s_module = module;
|
|
|
|
}
|
2004-07-01 14:49:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* set the global variable to point to the first initialize module */
|
2004-08-28 01:15:19 +00:00
|
|
|
if(s_module == NULL) {
|
2005-07-21 20:21:57 +00:00
|
|
|
opal_output_verbose(10, mca_oob_base_output, "mca_oob_base_init: no OOB modules available\n");
|
2005-03-18 03:43:59 +00:00
|
|
|
return ORTE_ERROR;
|
2004-08-28 01:15:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
mca_oob = *s_module;
|
2005-03-18 03:43:59 +00:00
|
|
|
return ORTE_SUCCESS;
|
2004-07-01 14:49:54 +00:00
|
|
|
}
|
|
|
|
|
2004-08-10 22:11:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Obtains the contact info (oob implementation specific) URI strings through
|
|
|
|
* which this process can be contacted on an OOB channel.
|
|
|
|
*
|
2004-08-10 22:30:21 +00:00
|
|
|
* @return A null terminated string.
|
2004-08-10 22:11:31 +00:00
|
|
|
*
|
2004-08-10 22:30:21 +00:00
|
|
|
* The caller is responsible for freeing the returned string.
|
2004-08-10 22:11:31 +00:00
|
|
|
*/
|
|
|
|
|
2004-08-10 22:30:21 +00:00
|
|
|
char* mca_oob_get_contact_info()
|
2004-08-10 22:11:31 +00:00
|
|
|
{
|
2005-03-14 20:57:21 +00:00
|
|
|
char *proc_name=NULL;
|
2004-08-16 19:39:54 +00:00
|
|
|
char *proc_addr = mca_oob.oob_get_addr();
|
2005-03-14 20:57:21 +00:00
|
|
|
char *contact_info=NULL;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ns.get_proc_name_string(&proc_name,
|
|
|
|
orte_process_info.my_name))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (0 > asprintf(&contact_info, "%s;%s", proc_name, proc_addr)) {
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
}
|
2004-08-16 19:39:54 +00:00
|
|
|
free(proc_name);
|
|
|
|
free(proc_addr);
|
|
|
|
return contact_info;
|
2004-08-10 22:11:31 +00:00
|
|
|
}
|
2004-08-16 19:39:54 +00:00
|
|
|
|
2004-08-24 16:54:45 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Setup the contact information for the seed daemon - which
|
|
|
|
* is passed as an MCA parameter.
|
|
|
|
*
|
|
|
|
* @param seed
|
|
|
|
*/
|
|
|
|
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
int mca_oob_set_contact_info(const char* contact_info)
|
2004-08-24 16:54:45 +00:00
|
|
|
{
|
2005-03-14 20:57:21 +00:00
|
|
|
orte_process_name_t name;
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
char** uri;
|
|
|
|
char** ptr;
|
|
|
|
int rc = mca_oob_parse_contact_info(contact_info, &name, &uri);
|
2005-03-18 03:43:59 +00:00
|
|
|
if(rc != ORTE_SUCCESS)
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
return rc;
|
|
|
|
|
|
|
|
for(ptr = uri; ptr != NULL && *ptr != NULL; ptr++) {
|
2005-07-03 16:22:16 +00:00
|
|
|
opal_list_item_t* item;
|
|
|
|
for (item = opal_list_get_first(&mca_oob_base_modules);
|
|
|
|
item != opal_list_get_end(&mca_oob_base_modules);
|
|
|
|
item = opal_list_get_next(item)) {
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
mca_oob_base_info_t* base = (mca_oob_base_info_t *) item;
|
|
|
|
if (strncmp(base->oob_component->oob_base.mca_component_name, *ptr,
|
|
|
|
strlen(base->oob_component->oob_base.mca_component_name)) == 0)
|
|
|
|
base->oob_module->oob_set_addr(&name, *ptr);
|
|
|
|
}
|
|
|
|
}
|
2004-08-28 01:15:19 +00:00
|
|
|
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
if(uri != NULL) {
|
2005-07-04 00:13:44 +00:00
|
|
|
opal_argv_free(uri);
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 03:59:06 +00:00
|
|
|
}
|
2005-03-18 03:43:59 +00:00
|
|
|
return ORTE_SUCCESS;
|
2004-08-28 01:15:19 +00:00
|
|
|
}
|
|
|
|
|
2004-08-19 19:34:37 +00:00
|
|
|
/**
|
|
|
|
* Called to request the selected oob components to
|
|
|
|
* register their address with the seed deamon.
|
|
|
|
*/
|
|
|
|
|
2004-08-25 17:39:08 +00:00
|
|
|
int mca_oob_base_module_init(void)
|
2004-08-19 19:34:37 +00:00
|
|
|
{
|
2005-07-03 16:22:16 +00:00
|
|
|
opal_list_item_t* item;
|
2004-08-19 19:34:37 +00:00
|
|
|
|
|
|
|
/* Initialize all modules after oob/gpr/ns have initialized */
|
2005-07-03 16:22:16 +00:00
|
|
|
for (item = opal_list_get_first(&mca_oob_base_modules);
|
|
|
|
item != opal_list_get_end(&mca_oob_base_modules);
|
|
|
|
item = opal_list_get_next(item)) {
|
2004-08-19 19:34:37 +00:00
|
|
|
mca_oob_base_info_t* base = (mca_oob_base_info_t *) item;
|
|
|
|
if (NULL != base->oob_module->oob_init)
|
|
|
|
base->oob_module->oob_init();
|
|
|
|
}
|
2005-03-18 03:43:59 +00:00
|
|
|
return ORTE_SUCCESS;
|
2004-08-19 19:34:37 +00:00
|
|
|
}
|
2004-09-09 23:38:18 +00:00
|
|
|
|