Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] [EXTERNAL] Re: [OMPI svn] svn:open-mpi r28202 - in trunk: ompi/runtime opal/mca/memory/linux
From: Ralph Castain (rhc_at_[hidden])
Date: 2013-03-22 11:35:00

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/ 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_at_bend001 .libs]$ nm | 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
> --
> Brian W. Barrett
> Scalable System Software Group
> Sandia National Laboratories
> _______________________________________________
> devel mailing list
> devel_at_[hidden]