Thanks for the explanation. It kinda begs a question, though - I've noticed
that the assignment of epoch seems to circle around in a number of places. We
call the ess_base function to get_epoch, and then we assign an epoch. But the
base function actually seem to do much, if anything.
It's
The warnings issued through ess_base_select.c:46 are annoying but harmless.
Wesley is going to hunt them and remove them, but they are really issued
because of the print:
orte_ess_base_proc_get_epoch (ess_base_select.c:46) calls
ORTE_NAME_PRINT(proc), which prints proc->epoch, before
I don't think these are anything to worry about since they're all print
statements, but I will work on these tonight.
On Fri, Aug 5, 2011 at 3:03 PM, Jeff Squyres wrote:
> Ralph and I are trying to track down the mysterious ORTE error.
>
> In doing so, I have found at least
BTW, the -1 file has an invalid free in it that we just fixed. That's not part
of the epoch value issue, of course. :-)
On Aug 5, 2011, at 3:03 PM, Jeff Squyres wrote:
> Ralph and I are trying to track down the mysterious ORTE error.
>
> In doing so, I have found at least one fairly
Ralph and I are trying to track down the mysterious ORTE error.
In doing so, I have found at least one fairly repeatable error on my cluster:
when running through SLURM the ibm/dynamic/spawn test, where we mpirun 3 procs
and then we MPI_COMM_SPAWN 3 more. Running the orteds through valgrind,
On Aug 5, 2011, at 5:55 AM, Brice Goglin wrote:
>> Libtool's -all-static flag probably resolves to some gcc flag(s), right?
>> Can you just pass those in via CFLAGS / LDFLAGS to configure and then not
>> pass anything in via make?
>
> I only see an additional -static flag on the final
Le 04/08/2011 02:24, Jeff Squyres a écrit :
> Libtool's -all-static flag probably resolves to some gcc flag(s), right? Can
> you just pass those in via CFLAGS / LDFLAGS to configure and then not pass
> anything in via make?
I only see an additional -static flag on the final program-link gcc