openmpi 3.1.5 references private glibc symbol __mmap

[opoplawski]

Thank you for taking the time to submit an issue!

Background information

What version of Open MPI are you using? (e.g., v1.10.3, v2.1.0, git branch name and hash, etc.)

3.1.5

Describe how Open MPI was installed (e.g., from a source/distribution tarball, from a git clone, from an operating system distribution package, etc.)

This is the Fedora 30 openmpi package

Details of the problem

I'm trying to update the Fedora 30 package from openmpi 3.1.4 to 3.1.5, but it cannot be installed:

Error: transaction check vs depsolve:
libc.so.6(GLIBC_PRIVATE)(64bit) is needed by openmpi-3.1.5-1.fc30.x86_64

This appears to be referenced by:

$ readelf -a usr/lib64/openmpi/lib/libopen-pal.so.40.10.5

Relocation section '.rela.plt' at offset 0x1bab0 contains 607 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000009f108  001400000007 R_X86_64_JUMP_SLO 0000000000000000 __mmap@GLIBC_PRIVATE + 0

This appears to have be caused by commit 8be0a233c87dc85871acb49a8e9c7b5c6381fbc3:

Author: Mark Allen <markalle@us.ibm.com>
Date:   Wed Mar 27 14:12:20 2019 -0400

    shmat/shmdt additions for patcher

    This is mostly based off recent UCX additions to their patcher:
        https://github.com/openucx/ucx/pull/2703

    They added triggers for
    * mmap when (flags & MAP_FIXED) && (addr != NULL)
    * shmat when (shmflg & SHM_REMAP) && (shmaddr != NULL)

    Beyond that I noticed they already had a trigger for
    * madvise when (advice == MADV_FREE)
    that we didn't so I added that.

    And the other main thing is we didn't really have shmat/shmdt
    active for some systems because we only had a path for
    syscall(SYS_shmdt, ) but we needed to also have a path for
    syscall(SYS_ipc, IPCOP_shmdt, ) and same for shmat.

    Signed-off-by: Mark Allen <markalle@us.ibm.com>
    (cherry picked from commit eb888118e83f56c131aff900b03eab34c92b7805)

which changed:

--- a/opal/mca/memory/patcher/memory_patcher_component.c
+++ b/opal/mca/memory/patcher/memory_patcher_component.c
@@ -104,15 +107,7 @@ opal_memory_patcher_component_t mca_memory_patcher_component = {
  * data. If this can be resolved the two levels can be joined.
  */

-/*
- * The following block of code is #if 0'ed out because we do not need
- * to intercept mmap() any more (mmap() only deals with memory
- * protection; it does not invalidate any rcache entries for a given
- * region).  But if we do someday, this is the code that we'll need.
- * It's a little non-trivial, so we might as well keep it (and #if 0
- * it out).
- */
-#if 0
+#if defined (SYS_mmap)

 #if defined(HAVE___MMAP) && !HAVE_DECL___MMAP
 /* prototype for Apple's internal mmap function */

I'm assuming that SYS_mmap is getting defined. configure reports:

checking whether __mmap is declared... no
checking for __mmap... yes
checking whether __syscall is declared... no
checking for __syscall... no

See also #6853

[hjelmn]

Thought we fixed this. The __mmap that configure was checking for was the one in macOS. We have since removed support for memory hooks in macOS and the check was removed.

[rhc54]

Looks like the code got re-activated by the referenced commit and probably shouldn't have been 😞

[mwheinz]

I just hit this problem as well, on RHEL 8.0. For some reason it builds and installs fine in RHEL 7.6.

[LINUX hdsmpriv01 20191209_1512 MPI]# rpm -ivf --force openmpi_gcc_hfi-3.1.5-90.el8.x86_64.rpm error: Failed dependencies: libc.so.6(GLIBC_PRIVATE)(64bit) is needed by openmpi_gcc_hfi-3.1.5-90.el8.x86_64

[rhc54]

I would suggest reverting https://github.com/open-mpi/ompi/commit/8be0a233c87dc85871acb49a8e9c7b5c6381fbc3 as it is clearly incorrect for the general case.

[jjhursey]

@markalle The hash Ralph cited is for a patch from you. Can you take a look?

[hppritcha]

actually it looks like commit fbbacc13 effectively reverted commit 8be0a23 on v4.0.x

[markalle]

I think the reference to https://github.com/open-mpi/ompi/issues/6853 is right. That's saying the infinite recursion fix that went into master needs to go into v4.0.x and v3.0.x. And it looks like it did make it into v4.0.x but not v3.0.x yet.

[mwheinz]

I think the reference to #6853 is right.

I'll do a quick test.

[jsquyres]

@opoplawski We should now have this fixed in the v3.0.x and v3.1.x branches. It was already fixed on master and v4.0.x (i.e., the fix was included in v4.0.2). Can you test a snapshot v3.1.x tarball after tonight's (17 Dec 2019) build?

https://www.open-mpi.org/nightly/v3.1.x/

[opoplawski]

openmpi-v3.1.x-201912180308-dd5ac63 looks good, thanks!

[opoplawski]

Will there be a 3.1.6 release soon?

[jsquyres]

We're working on it; we're in rc2 at the moment. I'm going to close this because the issue is resolved.