April 2016 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Jed Brown 21 Apr '16

21 Apr '16

Lisandro Dalcin <dalcinl(a)gmail.com> writes: >> If we allow --single-library=0, I do not see how we can avoid this. > > Shouldn't MPI static be linked only in libpetscsys? That should work... So you want the MPI symbols to be inlined into libpetscsys.so, then every other component that needs MPI will directly link libpetscsys.so?

1 0

--with-shared-libraries=1 is a happy camper if it ends up using a static linker
by Barry Smith 21 Apr '16

21 Apr '16

Hmm, when someone explicitly sets --with-shared-libraries=1 I think they would be rather upset if configure ends up using ar and static libraries because it could not find options to build shared libraries. Yet that is what happens now! Could someone add support so that if a user specifically requests --with-shared-libraries=1 configure barfs with a nice error message if it cannot find any? I think it is a trivial code change but does require the snippet go in exactly the right place which I cannot determine Thanks Barry

1 0

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Lisandro Dalcin 21 Apr '16

21 Apr '16

On 21 April 2016 at 20:08, Matthew Knepley <knepley(a)gmail.com> wrote: > PETSc used to have multiple shared libraries, and its still possible. If you > link MPI statically into multiple shared libraries, > you duplicate symbols like isInitialized. This messes up tons of things in > MPI. > >> >> 2) Is there any way to get rid of this flag or will there be cases were >> configure goes through with success and accepts using shared libraries but >> then the build fails with unable to make the PETSc shared library? > > > If we allow --single-library=0, I do not see how we can avoid this. Shouldn't MPI static be linked only in libpetscsys? That should work... -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

Re: [petsc-dev] RDict.log
by Satish Balay 21 Apr '16

21 Apr '16

On Tue, 19 Apr 2016, Lisandro Dalcin wrote: > Satish and Barry, two quick questions: > > * Shouldn't RDict.log be stored in > $PETSC_DIR/$PETSC_ARCH/lib/petsc/conf and symlinked to $PETSC_DIR, > just like configure.log and make.log? Yes - and I don't think we need the link for it. > > * Do we really need to keep the configure.log.bkp (actually, any > *.log.bkp) symlink? If all logs go to $PETSC_ARCH/lib/petsc/conf, > these *.log.bkp seems unnecessary clutter to me. There was a time - when we wanted to look at all the previous failed (configure) attempts the user invoked to understand the current problem - so we would concatinate to configure.log [instead of replacing it on each configure invocation] Obviously it had its drawbacks - so .log.bkp was a way of keeping the previous log [to look at if needed] - and configure.log was recreated each time. Perhaps *.log.bkp are not needed anymore - and we can get rid of them now. The links for configure.log and make.log cause other issues [links don't work on windows native tools aka mailers, simultaneous build in different PETSC_ARCH can still conflict on these files]. But its still good to have for most users. With configure.log getting much bigger now - we should compress it by default now.. Satish

1 0

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Barry Smith 21 Apr '16

21 Apr '16

> On Apr 21, 2016, at 2:09 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: >> We generate (or should if we don't) our shared PETSc libraries by >> >> sharedlink petscsys.so -lmpi >> >> sharedlink petscvec.so -lpetscsys > > If your shared libraries are set up correctly and there is a strict > policy about transitive linking (the correct thing), then this is not > okay because petscvec.so has direct calls to MPI. If libmpi.a (built > with -fPIC) was inlined into petscsys.so, then it would "work" (but be > disgusting). But this means, in general, that one cannot mix static and shared libraries if the static libraries have any global variables? Thus Matt is correct that we need to have MPI shared library if we have multiple PETSc libraries

1 0

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Jed Brown 21 Apr '16

21 Apr '16

Barry Smith <bsmith(a)mcs.anl.gov> writes: > We generate (or should if we don't) our shared PETSc libraries by > > sharedlink petscsys.so -lmpi > > sharedlink petscvec.so -lpetscsys If your shared libraries are set up correctly and there is a strict policy about transitive linking (the correct thing), then this is not okay because petscvec.so has direct calls to MPI. If libmpi.a (built with -fPIC) was inlined into petscsys.so, then it would "work" (but be disgusting).

1 0

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Barry Smith 21 Apr '16

21 Apr '16

> On Apr 21, 2016, at 12:08 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Wed, Apr 20, 2016 at 2:09 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > When running with --batch one must provide the flag --known-mpi-shared-library this is annoying since no one will know this > > I am trying to understand the purpose of this flag. It is used in MPI.py in the code > > def checkSharedLibrary(self): > '''Sets flag indicating if MPI libraries are shared or not and > determines if MPI libraries CANNOT be used by shared libraries''' > self.executeTest(self.configureMPIEXEC) > try: > self.shared = self.libraries.checkShared('#include <mpi.h>\n','MPI_Init','MPI_Initialized','MPI_Finalize',checkLink = self.checkPackageLink,libraries = self.lib, defaultArg = 'known-mpi-shared-libraries', executor = self.mpiexec) > except RuntimeError, e: > if self.argDB['with-shared-libraries']: > raise RuntimeError('Shared libraries cannot be built using MPI provided.\nEither rebuild with --with-shared-libraries=0 or rebuild MPI with shared library support') > self.logPrint('MPI libraries cannot be used with shared libraries') > self.shared = 0 > return > > It looks to me like the code says that if MPI is not a shared library then you cannot build PETSc with a shared library. > > 1) Is this true? What if MPI was built with PIC but static, won't it still be possible to use it with a PETSc shared library? i.e. is this even the right test? > > PETSc used to have multiple shared libraries, and its still possible. If you link MPI statically into multiple shared libraries, > you duplicate symbols like isInitialized. This messes up tons of things in MPI. Matt, We generate (or should if we don't) our shared PETSc libraries by sharedlink petscsys.so -lmpi sharedlink petscvec.so -lpetscsys etc. If it is done this way then will the problem with duplicate symbols be an issue? What if we make them with sharedlink petscsys.so -lmpi sharedlink petscvec.so -lpetscsys -lmpi etc. Maybe it is impossible to do the first case since we cannot remove from the link libraries "just" the MPI libraries whatever they happen to be? Barry > > 2) Is there any way to get rid of this flag or will there be cases were configure goes through with success and accepts using shared libraries but then the build fails with unable to make the PETSc shared library? > > If we allow --single-library=0, I do not see how we can avoid this. Could we not require --known-mpi-shared-libraries when --single-library=1 (which is the usual case most users will see?) > > Matt > > Thanks for any input > > Barry > > > > > > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener

1 0

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Matthew Knepley 21 Apr '16

21 Apr '16

On Wed, Apr 20, 2016 at 2:09 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > When running with --batch one must provide the flag > --known-mpi-shared-library this is annoying since no one will know this > > I am trying to understand the purpose of this flag. It is used in > MPI.py in the code > > def checkSharedLibrary(self): > '''Sets flag indicating if MPI libraries are shared or not and > determines if MPI libraries CANNOT be used by shared libraries''' > self.executeTest(self.configureMPIEXEC) > try: > self.shared = self.libraries.checkShared('#include > <mpi.h>\n','MPI_Init','MPI_Initialized','MPI_Finalize',checkLink = > self.checkPackageLink,libraries = self.lib, defaultArg = > 'known-mpi-shared-libraries', executor = self.mpiexec) > except RuntimeError, e: > if self.argDB['with-shared-libraries']: > raise RuntimeError('Shared libraries cannot be built using MPI > provided.\nEither rebuild with --with-shared-libraries=0 or rebuild MPI > with shared library support') > self.logPrint('MPI libraries cannot be used with shared libraries') > self.shared = 0 > return > > It looks to me like the code says that if MPI is not a shared library > then you cannot build PETSc with a shared library. > > 1) Is this true? What if MPI was built with PIC but static, won't it still > be possible to use it with a PETSc shared library? i.e. is this even the > right test? > PETSc used to have multiple shared libraries, and its still possible. If you link MPI statically into multiple shared libraries, you duplicate symbols like isInitialized. This messes up tons of things in MPI. > 2) Is there any way to get rid of this flag or will there be cases were > configure goes through with success and accepts using shared libraries but > then the build fails with unable to make the PETSc shared library? > If we allow --single-library=0, I do not see how we can avoid this. Matt > Thanks for any input > > Barry > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] --known-mpi-shared-library and --with-batch annoyance
by Lisandro Dalcin 21 Apr '16

21 Apr '16

On 20 April 2016 at 22:09, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > When running with --batch one must provide the flag --known-mpi-shared-library this is annoying since no one will know this > > I am trying to understand the purpose of this flag. It is used in MPI.py in the code > > def checkSharedLibrary(self): > '''Sets flag indicating if MPI libraries are shared or not and > determines if MPI libraries CANNOT be used by shared libraries''' > self.executeTest(self.configureMPIEXEC) > try: > self.shared = self.libraries.checkShared('#include <mpi.h>\n','MPI_Init','MPI_Initialized','MPI_Finalize',checkLink = self.checkPackageLink,libraries = self.lib, defaultArg = 'known-mpi-shared-libraries', executor = self.mpiexec) > except RuntimeError, e: > if self.argDB['with-shared-libraries']: > raise RuntimeError('Shared libraries cannot be built using MPI provided.\nEither rebuild with --with-shared-libraries=0 or rebuild MPI with shared library support') > self.logPrint('MPI libraries cannot be used with shared libraries') > self.shared = 0 > return > > It looks to me like the code says that if MPI is not a shared library then you cannot build PETSc with a shared library. I don't get what checkShared() is trying to do. > > 1) Is this true? What if MPI was built with PIC but static, won't it still be possible to use it with a PETSc shared library? i.e. is this even the right test? > If MPI is static but PIC, for sure you can build a shared PETSc. > > 2) Is there any way to get rid of this flag or will there be cases were configure goes through with success and accepts using shared libraries but then the build fails with unable to make the PETSc shared library? > To check if you can build a PETSc shared with an MPI static, you just need to create a shared library with some routine calling eg. MPI_Init()/Finalize(), not run any code (so the --batch flag is irrelevant). If MPI is static but not PIC, and you attempt to build any shared lib, most likely you will get a linker error, no need to run any executable. -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

--known-mpi-shared-library and --with-batch annoyance
by Barry Smith 20 Apr '16

20 Apr '16

When running with --batch one must provide the flag --known-mpi-shared-library this is annoying since no one will know this I am trying to understand the purpose of this flag. It is used in MPI.py in the code def checkSharedLibrary(self): '''Sets flag indicating if MPI libraries are shared or not and determines if MPI libraries CANNOT be used by shared libraries''' self.executeTest(self.configureMPIEXEC) try: self.shared = self.libraries.checkShared('#include <mpi.h>\n','MPI_Init','MPI_Initialized','MPI_Finalize',checkLink = self.checkPackageLink,libraries = self.lib, defaultArg = 'known-mpi-shared-libraries', executor = self.mpiexec) except RuntimeError, e: if self.argDB['with-shared-libraries']: raise RuntimeError('Shared libraries cannot be built using MPI provided.\nEither rebuild with --with-shared-libraries=0 or rebuild MPI with shared library support') self.logPrint('MPI libraries cannot be used with shared libraries') self.shared = 0 return It looks to me like the code says that if MPI is not a shared library then you cannot build PETSc with a shared library. 1) Is this true? What if MPI was built with PIC but static, won't it still be possible to use it with a PETSc shared library? i.e. is this even the right test? 2) Is there any way to get rid of this flag or will there be cases were configure goes through with success and accepts using shared libraries but then the build fails with unable to make the PETSc shared library? Thanks for any input Barry

1 0