Re: [OMPI devel] configure problem on master
Ralph, just wanted to confirm that the lustre configure issue seems in fact solved on master. Thanks! Edgar From: devel On Behalf Of Ralph Castain via devel Sent: Thursday, February 4, 2021 2:02 PM To: OpenMPI Devel Cc: Ralph Castain 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 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
Re: [OMPI devel] configure problem on master
Gilles, thank for identifying the problem. Do you know by any chance what might trigger this change/issue? The configure script for that component has not changed in 4 years according to git. Thanks! Edgar -Original Message- From: devel On Behalf Of Gilles Gouaillardet via devel Sent: Friday, February 5, 2021 8:39 PM To: Open MPI Developers Cc: Gilles Gouaillardet Subject: Re: [OMPI devel] configure problem on master Edgar and Jeff, the root cause is we do not use pthreads here any more: From master config.log configure:226861: gcc -std=gnu99 -o conftest -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -mcx16 -I/home/usersup/gilles/build/ompi-master/3rd-party/openpmix/include -I/home/usersup/gilles/src/ompi-master/3rd-party/openpmix/include -I/usr/local/include -I/usr/local/include conftest.c -lrt -lm -lutil >&5 /usr/bin/ld: /tmp/ccDiuQBc.o: undefined reference to symbol 'sem_open@@GLIBC_2.2.5' //usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status The test passes on v4.1.x because the '-pthread' flag is passed Cheers, Gilles On Sat, Feb 6, 2021 at 11:27 AM Gabriel, Edgar via devel wrote: > > The library that contains sem_init and sem_open, the two functions > that we check for in the configure script > > > > From: Jeff Squyres (jsquyres) > Sent: Friday, February 5, 2021 7:31 PM > To: Open MPI Developers List > Cc: Gabriel, Edgar > Subject: Re: [OMPI devel] configure problem on master > > > > Which library? > > > > On Feb 5, 2021, at 4:46 PM, Gabriel, Edgar via devel > 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 On Behalf Of Gabriel, > Edgar via devel > Sent: Thursday, February 4, 2021 2:15 PM > To: Open MPI Developers > Cc: Gabriel, Edgar > 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 On Behalf Of Ralph > Castain via devel > Sent: Thursday, February 4, 2021 2:02 PM > To: OpenMPI Devel > Cc: Ralph Castain > 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 > wrote: > > > > I have a weird problem running configure on master on our clust
Re: [OMPI devel] configure problem on master
Edgar and Jeff, the root cause is we do not use pthreads here any more: >From master config.log configure:226861: gcc -std=gnu99 -o conftest -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -mcx16 -I/home/usersup/gilles/build/ompi-master/3rd-party/openpmix/include -I/home/usersup/gilles/src/ompi-master/3rd-party/openpmix/include -I/usr/local/include -I/usr/local/include conftest.c -lrt -lm -lutil >&5 /usr/bin/ld: /tmp/ccDiuQBc.o: undefined reference to symbol 'sem_open@@GLIBC_2.2.5' //usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status The test passes on v4.1.x because the '-pthread' flag is passed Cheers, Gilles On Sat, Feb 6, 2021 at 11:27 AM Gabriel, Edgar via devel wrote: > > The library that contains sem_init and sem_open, the two functions that we > check for in the configure script > > > > From: Jeff Squyres (jsquyres) > Sent: Friday, February 5, 2021 7:31 PM > To: Open MPI Developers List > Cc: Gabriel, Edgar > Subject: Re: [OMPI devel] configure problem on master > > > > Which library? > > > > On Feb 5, 2021, at 4:46 PM, Gabriel, Edgar via devel > 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 On Behalf Of Gabriel, Edgar > via devel > Sent: Thursday, February 4, 2021 2:15 PM > To: Open MPI Developers > Cc: Gabriel, Edgar > 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 On Behalf Of Ralph Castain via > devel > Sent: Thursday, February 4, 2021 2:02 PM > To: OpenMPI Devel > Cc: Ralph Castain > 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 > 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 s
Re: [OMPI devel] configure problem on master
The library that contains sem_init and sem_open, the two functions that we check for in the configure script From: Jeff Squyres (jsquyres) Sent: Friday, February 5, 2021 7:31 PM To: Open MPI Developers List Cc: Gabriel, Edgar Subject: Re: [OMPI devel] configure problem on master Which library? On Feb 5, 2021, at 4:46 PM, Gabriel, Edgar via devel 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 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 mailto:devel@lists.open-mpi.org>> Cc: Gabriel, Edgar 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 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 mailto:devel@lists.open-mpi.org>> Cc: Ralph Castain 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 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 chec
Re: [OMPI devel] configure problem on master
Which library? On Feb 5, 2021, at 4:46 PM, Gabriel, Edgar via devel 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 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 mailto:devel@lists.open-mpi.org>> Cc: Gabriel, Edgar 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 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 mailto:devel@lists.open-mpi.org>> Cc: Ralph Castain 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 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
Re: [OMPI devel] configure problem on master
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 On Behalf Of Gabriel, Edgar via devel Sent: Thursday, February 4, 2021 2:15 PM To: Open MPI Developers Cc: Gabriel, Edgar 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 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 mailto:devel@lists.open-mpi.org>> Cc: Ralph Castain 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 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 contain
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 On Behalf Of Ralph Castain via devel Sent: Thursday, February 4, 2021 2:02 PM To: OpenMPI Devel Cc: Ralph Castain 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 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
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 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
