Created attachment 18573 [details] adapt autoconf to possibly renamed pmix symbols Dear Team Building Slurm (20.11.4) from the spec-file against a PMIx with symbol renaming currently fails. Environment: - RHEL 8.2, PPC64LE - Slurm 20.11.4, source - OpenMPI (v4.0.3rc3-36-gfaa1bdc) via Mellanox OFED (4.9-2.2.4.1) - PMIx (as shipped with OFED, pmix3x (MCA v2.1.0, API v2.0.0, Component v4.0.3)) Cause: x_ac_pmix.m4 tries to find the PMIx-Library via linking and uses PMIx_Get_version. However, in our PMIx, this symbol is renamed: # nm /usr/mpi/gcc/openmpi-4.0.3rc4/lib64/libpmix.so |grep PMIx_Get_version 000000000006baa0 T OPAL_MCA_PMIX3X_PMIx_Get_version Indeed, at compile-time, a renaming happens: # grep PMIx_Get_version /usr/mpi/gcc/openmpi-4.0.3rc4/include/pmix_rename.h #define PMIx_Get_version OPAL_MCA_PMIX3X_PMIx_Get_version This is included in pmix_common.h, which should be safe to assume present once the include dir is found. x_ac_pmix.m4 relies on autoconf to generate the C code for building against the possbile libraries. A tiny patch to include pmix_common.h is sufficient to pick up the renaming and does not harm in non-renamed cirumstances: - [AC_LANG_CALL([], PMIx_Get_version)], + [AC_LANG_PROGRAM([[#include<pmix_common.h>]], [[(void)PMIx_Get_version()]])], Best regards -Tobias Pape for the SCORE Lab at HPI Germany [This is our first entry here. Please tell us in case we forgot anything]
[is it possible to reclassify this as "contribution"?]
[thanks]