Re: [opensuse-science] openmpi3 pulled as dep
Hi Nicolas, Nicolas Morey-Chaisemartin writes:
Le 10/21/20 à 9:58 AM, Nicolas Morey-Chaisemartin a écrit :
Le 10/21/20 à 9:35 AM, Egbert Eich a écrit :
Hi Alin,
please specify what system you are using (Leap<version>, Tumbleweed ...). It seems you are mixing HPC (openmpi4-gnu-hpc-devel) and non-HPC packages. Moreover, there is no scalapack-openmpi4 (not even among the non-HPC packages).
There is a bit of a problem with MPI depenendencies with non-HPC packages. It seems like both openmpi3 and 4 provide libmpi.so.40()(64bit). @Nicolas - is this correct?
Yes they do. But in theory, packages depending on a specific MPI version like this should require the right openmpi, not just the libmpi.so
Yes, this is what we do for the HPC versions. We even strip these 'generic' library dependencies from the list using our own dependency generator.
WHich lapack does not seem to be doing/ BuildRequires: %{mpi_flavor}%{?mpi_ext}-devel
It's only a BuildRequires but a Requires: %{mpi_flavor}%{?mpi_ext}-libs is also needed.
Scratch some of that (it works but there is a newer/better way) openmpi* packages were cleaned up some time back. What should be done for all openmpi (at least non hpc) dependant packages is: BuildRequires: openmpi<N>-macros-devel
Ok. Is this available or all MPI flavors? If so, we could just do a: BuildRequires: %{mpi}-macros-devel The define of %mpi should be avaiable to the build dependency script as it doesn't depend on other macro packages. If this is the case I will make adjustments when visiting packages again.
It'll provide the macros: %setup_openmpi # (Load the orpper mpivars.sh) %openmpi_requires # ( Add the right Requires:..... for the openmpi package) %openmpi_devel_requires # same but for devel packages)
Also for using the "default" version of openmpi (currently openmpi2), you can juste BuildRequires: openmpi-macros-devel. It'll pull the macros from the default version so there is no need to specify which one and it can be changed more easily when we decide to go to openmpi 3 or 4 by default.
Right. Ok, this should work as well - if 'openmpi' stands for 'openmpi-default' instead of 'openmpi1' it'd be fine. We will build for openmpi2 twice then: once for 'default' and once for it explicitly and we don't build for openmpi1 at all. But maybe people don't care any more ... Thanks! Cheers, Egbert.
Nicolas
Nicolas
For the HPC variants this has been fixed. If both openmpi3 and openmpi4 provide the libmpi.so.4 ABI, then you will have to install openmpi4-libs explicitly, I'm afraid - or use the HPC variant of scalapack.
Cheers, Egbert.
Alin Marin Elena writes: > Hi. > > I try to install openmpi4 but somehow openmpi3 is pulled see below. > > drFaustroll@circassia:~> sudo zypper in scalapack-openmpi4 > openmpi4-gnu-hpc-devel > Problem retrieving files from 'oneAPI'. > Permission to access > 'https://yum.repos.intel.com/oneapi/media.1/media' denied. > Please see the above error message for a hint. > Warning: Skipping repository 'oneAPI' because of the above error. > Some of the repositories have not been refreshed because of an error. > Loading repository data... > Reading installed packages... > 'scalapack-openmpi4' not found in package names. Trying capabilities. > Resolving package dependencies... > > The following 31 NEW packages are going to be installed: > gcc-c++ gnu-compilers-hpc gnu-compilers-hpc-devel infiniband-diags > libfabric1 libibmad5 libibnetdisc5 libibumad3 libinfinipath4 > libopenmpi_4_0_5-gnu-hpc > libpsm2-2 libpsm_infinipath1 libscalapack2-openmpi4 libucm0 libucp0 > libucs0 libuct0 lua53 lua53-luafilesystem lua53-luaposix lua53-luaterm > lua-lmod > mpi-selector openmpi3 openmpi3-libs openmpi_4_0_5-gnu-hpc > openmpi_4_0_5-gnu-hpc-devel openmpi4-config openmpi4-gnu-hpc-devel > rdma-core-devel rsocket > > The following recommended package was automatically selected: > openmpi4-config > > 31 new packages to install. > > Without Questions there are no Answers! > ______________________________________________________________________ > Dr. Alin Marin ELENA > http://alin.elena.space/ > ______________________________________________________________________ > -- > To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org > To contact the owner, e-mail: opensuse-science+owner@opensuse.org
-- Egbert Eich (Res. & Dev.) SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org
Le 10/22/20 à 10:57 AM, Egbert Eich a écrit :
Hi Nicolas,
Nicolas Morey-Chaisemartin writes:
Is this available or all MPI flavors? If so, we could just do a: BuildRequires: %{mpi}-macros-devel
No it's only for openmpi* packages at the moment.
The define of %mpi should be avaiable to the build dependency script as it doesn't depend on other macro packages. If this is the case I will make adjustments when visiting packages again.
It'll provide the macros: %setup_openmpi # (Load the orpper mpivars.sh) %openmpi_requires # ( Add the right Requires:..... for the openmpi package) %openmpi_devel_requires # same but for devel packages)
Also for using the "default" version of openmpi (currently openmpi2), you can juste BuildRequires: openmpi-macros-devel. It'll pull the macros from the default version so there is no need to specify which one and it can be changed more easily when we decide to go to openmpi 3 or 4 by default.
Right. Ok, this should work as well - if 'openmpi' stands for 'openmpi-default' instead of 'openmpi1' it'd be fine.
It does. That's the reason openmpi was renamed to openmpi1 We will
build for openmpi2 twice then: once for 'default' and once for it explicitly and we don't build for openmpi1 at all. But maybe people don't care any more ...
You probably don't need that. The default flavor is mostly for package which don't really care which one they use (stuff like boost and other core libs) but you need all of them to use the same one. It was introduced as there was a huge mess of some libs building against openmpi1, some against openmpi2 so the stack wasn't working. Package like lapack where the pick of flavor might matter should build against all, not necesseraly against the default one. Nicolas -- To unsubscribe, e-mail: opensuse-science+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-science+owner@opensuse.org
participants (2)
-
Egbert Eich -
Nicolas Morey-Chaisemartin