The library that contains sem_init and sem_open, the two functions that we check for in the configure script
From: Jeff Squyres (jsquyres) <jsquy...@cisco.com> Sent: Friday, February 5, 2021 7:31 PM To: Open MPI Developers List <devel@lists.open-mpi.org> Cc: Gabriel, Edgar <egabr...@central.uh.edu> Subject: Re: [OMPI devel] configure problem on master Which library? On Feb 5, 2021, at 4:46 PM, Gabriel, Edgar via devel <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> wrote: I just noticed another ‘new’ aspect of configure on master. The sharedfp/sm component is now not compiled anymore, I double checked that it is still correctly detected and handled on 4.1, so it must be a recent change. On master: --snip-- --- MCA component sharedfp:sm (m4 configuration macro) checking for MCA component sharedfp:sm compile mode... dso checking semaphore.h usability... yes checking semaphore.h presence... yes checking for semaphore.h... yes checking for sem_open... no checking for semaphore.h... (cached) yes checking for sem_init... no checking if MCA component sharedfp:sm can compile... no --snip -- while e.g. on 4.1 on exactly the same platform: --snip-- --- MCA component sharedfp:sm (m4 configuration macro) checking for MCA component sharedfp:sm compile mode... dso checking semaphore.h usability... yes checking semaphore.h presence... yes checking for semaphore.h... yes checking for sem_open... yes checking for semaphore.h... (cached) yes checking for sem_init... yes checking if MCA component sharedfp:sm can compile... yes ---snip--- it looks like a library that is required for the semaphore operations was be default included previously, and is not anymore? Thanks Edgar From: devel <devel-boun...@lists.open-mpi.org<mailto:devel-boun...@lists.open-mpi.org>> On Behalf Of Gabriel, Edgar via devel Sent: Thursday, February 4, 2021 2:15 PM To: Open MPI Developers <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> Cc: Gabriel, Edgar <egabr...@central.uh.edu<mailto:egabr...@central.uh.edu>> Subject: Re: [OMPI devel] configure problem on master excellent, thanks! I have meanwhile a more detailed suspicion: -- looking for library without search path checking for library containing llapi_file_create... no looking for library in /opt/lustre/2.12.2/lib64 checking for library containing llapi_file_create... (cached) no -- the liblustrapi library is in the /opt/lustre/2.12.2/lib64, so the configure script should not be using the cached value (no) but really check again. This seems to be the key difference between the ompi and openpmix scripts. (for comparison the ompi output is looking for library in lib checking for library containing llapi_file_create... no looking for library in lib64 checking for library containing llapi_file_create... -llustreapi ) Thanks Edgar From: devel <devel-boun...@lists.open-mpi.org<mailto:devel-boun...@lists.open-mpi.org>> On Behalf Of Ralph Castain via devel Sent: Thursday, February 4, 2021 2:02 PM To: OpenMPI Devel <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> Cc: Ralph Castain <r...@open-mpi.org<mailto:r...@open-mpi.org>> Subject: Re: [OMPI devel] configure problem on master Sounds like I need to resync the PMIx lustre configury with the OMPI one - I'll do that. On Feb 4, 2021, at 11:56 AM, Gabriel, Edgar via devel <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> wrote: I have a weird problem running configure on master on our cluster. Basically, configure fails when I request lustre support, but not from ompio but openpmix. What makes our cluster setup maybe a bit special is that the lustre libraries are not installed in the standard path, but in /opt, and thus we provide the --with-lustre=/opt/lustre/2.12.2 as an option. If I remove the 3rd-party/openpmix/src/mca/pstrg/lustre component, the configure script finishes correctly. I looked at the ompi vs. openmpix check_lustre configure scripts, I could not detect on a quick glance any difference that would explain why the script is failing in one instance but not the other, but the openpmix version does seem to go through some additional hoops (checking separately for the include directory, the lib and lib64 directories etc), so it might be a difference in the PMIX_ macros vs. the OPAL_ macros. --snip-- --- MCA component fs:lustre (m4 configuration macro) checking for MCA component fs:lustre compile mode... dso checking --with-lustre value... sanity check ok (/opt/lustre/2.12.2) checking looking for lustre libraries and header files in... (/opt/lustre/2.12.2) checking lustre/lustreapi.h usability... yes checking lustre/lustreapi.h presence... yes checking for lustre/lustreapi.h... yes looking for library in lib checking for library containing llapi_file_create... no looking for library in lib64 checking for library containing llapi_file_create... -llustreapi checking if liblustreapi requires libnl v1 or v3... checking for required lustre data structures... yes checking if MCA component fs:lustre can compile... yes --snip -- --- MCA component pstrg:lustre (m4 configuration macro) checking for MCA component pstrg:lustre compile mode... dso checking --with-lustre value... sanity check ok (/opt/lustre/2.12.2) checking looking for lustre libraries and header files in... (/opt/lustre/2.12.2) looking for header in /opt/lustre/2.12.2 checking lustre/lustreapi.h usability... no checking lustre/lustreapi.h presence... no checking for lustre/lustreapi.h... no looking for header in /opt/lustre/2.12.2/include checking lustre/lustreapi.h usability... yes checking lustre/lustreapi.h presence... yes checking for lustre/lustreapi.h... yes looking for library without search path checking for library containing llapi_file_create... no looking for library in /opt/lustre/2.12.2/lib64 checking for library containing llapi_file_create... (cached) no looking for library in /opt/lustre/2.12.2/lib checking for library containing llapi_file_create... (cached) no configure: error: Lustre support requested but not found. Aborting --snip -- Does anybody have an idea on what could trigger this issue or a suggestion how to investigate it? Thanks Edgar -- Jeff Squyres jsquy...@cisco.com<mailto:jsquy...@cisco.com>
