On Mar 22, 2013, at 8:23 AM, "Barrett, Brian W" <bwbarre_at_[hidden]> wrote:
> On 3/22/13 9:17 AM, "Ralph Castain" <rhc_at_[hidden]> wrote:
>> I'm afraid this still doesn't work for me - on my Centos box:
>> ../../../ompi/.libs/libmpi.so: undefined reference to
>> 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_at_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?
>> 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 W. Barrett
> Scalable System Software Group
> Sandia National Laboratories
> devel mailing list