guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open MPI keeps references to GCC, GFortran, etc.


From: Ludovic Courtès
Subject: Re: Open MPI keeps references to GCC, GFortran, etc.
Date: Fri, 28 Jul 2017 10:10:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hi,

Dave Love <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> Hello,
>>
>> Open MPI retains references to GCC, GFortran, etc., which significantly
>> 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).

Interesting.  It’s not a “should” though IMO, in the sense that we add
additional inputs only when we have a good reason to do so.  For
example, in most cases, a “doc” output would only save you a few KiB of
man pages, representing .1% of the package size, so we don’t add a “doc”
output in those cases.  This is different from the Fedora/Debian
approach where packages are systematically split in several outputs.
The “Submitting Patches” section of the manual mentions this.

In the case of Open MPI, adding a “lib” output wouldn’t help: “out”
would still refer to gfortran via ‘ompi_info’, and “lib” would refer to
gfortran via opal_config.h.  Hence my suggestion to simply remove the
reference to gfortran & co.

> [It's not the only example of monstrous dependencies I've noticed
> trying to build things.]

Yeah I think it’s easy to overlook this when working on packages, but we
should constantly pay attention to this with ‘guix size’.

>> 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 ‘ompi_info’ and ‘oshmem_info’.
>
> I'm confused what the wrappers are doing,

The two commands return the actual compiler names, not the names of
wrappers:

--8<---------------cut here---------------start------------->8---
$ $(guix build openmpi)/bin/ompi_info

[...]

              C compiler: gcc
     C compiler absolute: 
/gnu/store/zlyn8z138s2vv86bdx9d72kchjczv0xn-gcc-5.4.0/bin/gcc
  C compiler family name: GNU
      C compiler version: 5.4.0
            C++ compiler: g++
   C++ compiler absolute: 
/gnu/store/zlyn8z138s2vv86bdx9d72kchjczv0xn-gcc-5.4.0/bin/g++
           Fort compiler: gfortran
       Fort compiler abs: 
/gnu/store/vcx02xlp6s92bxrcafnpw7hnqa4kc32b-gfortran-5.4.0/bin/gfortran
         Fort ignore TKR: yes (!GCC$ ATTRIBUTES NO_ARG_CHECK ::)
--8<---------------cut here---------------end--------------->8---

AIUI, this is “purely informational”.  Replacing the absolute file names
with just the base name won’t break anything.  Except that there’s
always the possibility of scripts or tools out there parsing the output
of ‘ompi_info’.  Thus my question was: do people really parse the output
of these commands, or can we safely assume that third-party programs
don’t rely on these absolute file names?

> I was intending to look at parameterizing the build on gfortran version,

I suppose you could to:

  (define openmpi-with-gfortran7
    (package
      (inherit openmpi)
      (name "openmpi-gfortran7")
      (inputs `(("gfortran" ,gfortran-7)
                ,@(alist-delete "gfortran" (package-inputs openmpi))))))

(That said, if the .mod files are compatible among gfortran versions, it
probably doesn’t make sense to do this.)

WDYT?

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]