From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Love Subject: Re: Open MPI keeps references to GCC, GFortran, etc. Date: Thu, 27 Jul 2017 14:45:44 +0100 Message-ID: <87d18mhu2f.fsf@i-ulialbion.it.manchester.ac.uk> References: <87vame5jgd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1daj6t-0001s3-9D for guix-devel@gnu.org; Thu, 27 Jul 2017 09:45:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1daj6q-0008Dl-2b for guix-devel@gnu.org; Thu, 27 Jul 2017 09:45:51 -0400 Received: from clarity.mcc.ac.uk ([130.88.200.144]:25218) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1daj6p-0008Ci-QD for guix-devel@gnu.org; Thu, 27 Jul 2017 09:45:47 -0400 In-Reply-To: <87vame5jgd.fsf@gnu.org> ("Ludovic \=\?iso-8859-1\?Q\?Court\=E8s\?\= \=\?iso-8859-1\?Q\?\=22's\?\= message of "Thu, 27 Jul 2017 11:15:46 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: guix-devel , Ricardo Wurmus , Eric Bavier Ludovic Court=C3=A8s writes: > Hello, > > Open=C2=A0MPI retains references to GCC, GFortran, etc., which significan= tly > increases its closure size. My query about cycles from separating the lib output was from looking at basically this. There should be a runtime package for compute nodes and a development one (as "openmpi" and "openmpi-devel" in Fedora). [It's not the only example of monstrous dependencies I've noticed trying to build things.] > The references come from cpp macros such as OMPI_FC_ABSOLUTE (absolute > file name of the Fortran compiler), defined in opal_config.h and > returned by command-line tools =E2=80=98ompi_info=E2=80=99 and =E2=80=98o= shmem_info=E2=80=99. I'm confused what the wrappers are doing, and would have to dig into the code to find out. "strings" on a version on our cluster doesn't actually show gfortran, and "mpifort -showme" doesn't have a path name for it. I think I've been here before, but have forgotten. > What would be the impact of changing these OMPI_*_ABSOLUTE uses to just > the basename of the compiler? Are there tools or practices that rely on > the info provided by these two commands? There should be no dependence on the C compiler. I can't say about C++, past the standard library version, but I think it's deprecated anyhow. Apart from minor ABI incompatibilities, as far as I know (and when they change the libfortran soname, sigh), the dependence on a specific version of gfortran is down to the highly annoying backwards incompatibility of the module file formats (e.g. mpi.mod). You can change the compiler at runtime with an environment variable (OMPI_FC (?)) and it will either work or fail according to the version of .mod files involved. It's annoying that the only real difference between painstakingly-built mpi packages for different gfortran versions is the .mod files. There are plenty of things which don't just use the compiler wrappers as they should and, I think some try their "-showme" options to get information. I can't immediately think of which do, and how, but I can have a look around at things I have packaged. I doubt it's worth worrying about, though. I was intending to look at parameterizing the build on gfortran version, which is basically a case of setting "FC" appropriately for configure (possibly rebuilding just the Fortran part for a list of FCs within one package build, and installing the module files in different places, which I've never got round to looking at with rpm). I'm not clear how dependencies are, or should be, propagated for different compilers, but guess it will be trivial. To support multiple gfortran versions, this also needs doing for the development part of any library packages that provide Fortran modules. [I can rant at length on the combinatorial build explosion that typically infects HPC installations. That's part of the interest in Guix, and I was initially looking at improving MPI stuff as something I understand from Fedora-land.] Should I carry on looking at separating out and parameterizing parts of openmpi, or will a Guix expert work on it? I'm currently stuck with figuring out the cycle from the build, but haven't put much effort into it, and it's not as simple as just turning on the "lib" output. I don't know whether that helps much, but I can probably answer questions on anything I might know more about than others.