Hi Gleb,
Tim and I have incorporated some of the changes you mentioned into a
new rcache framework. Currently there is a single component in this
framework, rcache_rb which is a registration cache based on a red-
black tree and uses an MRU list if the registration is not
persistent. Note
Here is a bit more on the sparc/linux SegFault from everything unless
configured with --enable-debug:
On Mon, 2005-09-12 at 13:34 -0500, Brian Barrett wrote:
> Ok, I see what's happening, although I'm not sure the two problems
> are actually related. The first is that the component to provide
On Wed, Sep 14, 2005 at 08:40:49AM -0600, Galen M. Shipman wrote:
> Hi Gleb,
Hello Galen,
I checked out the new code and am looking at it now. Thanks!
>
> Tim and I have incorporated some of the changes you mentioned into a
> new rcache framework. Currently there is a single component in this
Hi Nathan,
> Nathan DeBardeleben writes:
> >
> > I've been having this problem for a week or so and I've been asking
> > other people to weigh in if they know what I'm doing wrong. I've gotten
> > no where on this so I figure I'll finally drop it out on the list.
> > First, here's the importa
Jeff,
This error has been occurring during make for the last couple of days
(this error is from HEAD 7371).
Jim Barker
mkdir .libs
g++ -g -Wall -Wundef -Wno-long-long -finline-functions -pthread -o
ompi_info components.o ompi_info.o output.o param.o version.o
-Wl,--export-dynamic ../../../
I believe the problem is that you are trying to link statically, but
there is no static version of libnuma available (i.e., there's only
libnuma.so, not libnuma.a).
Hence, if you want libnuma support, you'll either have to generate a
libnuma.a file or compile Open MPI dynamically...
On S
Jeff - seems like a configure/build issue to me. Shouldn't we disable
numa support and not try to build it if the supporting libraries
don't exist?
Thanks,
Tim
Jeff Squyres wrote:
I believe the problem is that you are trying to link statically, but
there is no static version of libnuma availa
On Sep 14, 2005, at 5:40 PM, Tim S. Woodall wrote:
Jeff - seems like a configure/build issue to me. Shouldn't we disable
numa support and not try to build it if the supporting libraries
don't exist?
Not sure what you mean -- the supporting library *does* exist...? (just
not in the mode that y
Jeff Squyres wrote:
On Sep 14, 2005, at 5:40 PM, Tim S. Woodall wrote:
Jeff - seems like a configure/build issue to me. Shouldn't we disable
numa support and not try to build it if the supporting libraries
don't exist?
Not sure what you mean -- the supporting library *does* exist...? (just
I committed some code that should fix the timer problems on SPARC
linux. Can you either svn up and try again (or, if you are using
nightly builds) try tomorrow's tarball and see if it works? The test
tests/util/opal_timer.c should give an indication as to whether
everything is working ok
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Sep 2005, Brian Barrett wrote:
I committed some code that should fix the timer problems on SPARC
linux. Can you either svn up and try again (or, if you are using
nightly builds) try tomorrow's tarball and see if it works? The test
tests
On Sep 14, 2005, at 6:07 PM, Tim S. Woodall wrote:
Seriously, I can see your point, but I don't see an obvious fix -- we
don't check for the mode of the target library. We just check that
"$CC testprogram.c -L/path/to/libnuma -lnuma" works properly
(actually,
this is how *all* checks are done
I take this back entirely -- ignore everything I said.
There appear to be two problems:
- I borked up the libnuma configure.m4 such that mpicc (and friends)
don't get the right flags for libnuma when you compile OMPI statically.
- James' problem seems to be somewhat different -- he's failing
13 matches
Mail list logo
