More info: it works fine if I exec after the fork (or equivalently,
run anything via system). This provides a sufficient workaround at
least for me, so it's probably not worth complaining further that a
proprietarily modified decade old version of gdb doesn't work. :)
Thanks,
Geoffrey
On Fri, Fe
Meh. UDAPL never really caught on.
It was the low latency stack in Solaris for a while. Then they shifted to
verbs. Then Sun got bought by Oracle, and they didn't really care about UDAPL
anymore (at least from an HPC perspective).
Intel used to use UDAPL as their main communication layer f
You may find more updated version on ofed website:
http://www.openfabrics.org/downloads/dapl/
Pavel (Pasha) Shamis
---
Computer Science Research Group
Computer Science and Math Division
Oak Ridge National Laboratory
On Feb 22, 2013, at 2:18 PM, Orion Poplawski wrote:
> Is the uDAPL projec
Is the uDAPL project still active? The SourceForge page says it isn't:
http://sourceforge.net/projects/dapl/
As of 2009-03-13, this project is no longer under active development.
openmpi's configure emits;
checking --with-udapl value... simple ok (unspecified)
checking --with-udapl-libdir va
Geoffrey,
If I understand correctly your problem, I think it is a gdb issue. You should
inform gdb that after the fork call instead of following the parent you expect
to follow the child.
set follow-fork-mode child (should do the trick).
For more info: http://sourceware.org/gdb/onlinedocs/gdb/
No luck with gdb 7.5.1. I can get it to run, but it hits an internal
error and bails out. Thus, I'm stuck with Apple's 6.3.50. I suppose
I'll try to restructure the app so that I don't have to spawn the mpi
process with a fork from the other one.
Geoffrey
On Thu, Feb 21, 2013 at 4:38 PM, Geoff
