On Mar 22, 2013, at 8:23 AM, "Barrett, Brian W" <bwba...@sandia.gov> wrote:
> On 3/22/13 9:17 AM, "Ralph Castain" <r...@open-mpi.org> wrote: > >> I'm afraid this still doesn't work for me - on my Centos box: >> >> ../../../ompi/.libs/libmpi.so: undefined reference to >> `opal_memory_linux_malloc_init_hook' >> >> I tried it with a brand new checkout of the trunk. Any ideas? > > Can you run nm on the built libopen-pal and see if > opal_memory_linux_malloc_init_hook() is in there (and whether it's public > or private)? Here's what I see [rhc@bend001 .libs]$ nm libopen-pal.so | grep hook 00000000002f2900 b hooks_support 00000000000a29fa t opal_hwloc152_hwloc_set_linuxfs_hooks 000000000002aad5 T opal_mem_hooks_finalize 000000000002aa2d T opal_mem_hooks_init 000000000002ad5a T opal_mem_hooks_register_release 000000000002ac7d T opal_mem_hooks_release_hook 000000000002ac6b T opal_mem_hooks_set_support 000000000002ad4e T opal_mem_hooks_support_level 000000000002af5a T opal_mem_hooks_unregister_release Perhaps the difference stems from my platform file? with_memory_manager=no > >> IIRC, we wound up here because we were trying to avoid rolling libopal >> into liborte into libmpi and instead having three completely separable >> libraries. Given that we haven't been able to make that work across >> platforms, is it time to give up and return to what worked? > > No. It's important to the no orte case and I'm not giving it up because > OFED can't get it's act together and solve this properly (i.e., put > uumunotify in their stack). I'll take the bandwidth hit for IB before > I'll go back to broken library building. > > Brian > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
