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 <devel-boun...@lists.open-mpi.org> On Behalf Of Gilles Gouaillardet via devel Sent: Friday, February 5, 2021 8:39 PM To: Open MPI Developers <devel@lists.open-mpi.org> Cc: Gilles Gouaillardet <gilles.gouaillar...@gmail.com> 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 <devel@lists.open-mpi.org> 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) <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> 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> On Behalf Of Gabriel, > Edgar via devel > Sent: Thursday, February 4, 2021 2:15 PM > To: Open MPI Developers <devel@lists.open-mpi.org> > Cc: Gabriel, Edgar <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> On Behalf Of Ralph > Castain via devel > Sent: Thursday, February 4, 2021 2:02 PM > To: OpenMPI Devel <devel@lists.open-mpi.org> > Cc: Ralph Castain <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> 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 > >
