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

[Dave Love]

Ludovic Courtès <address@hidden> writes:

> My intent was to remove the *run-time* dependency of openmpi on gcc &
> co. (as returned by ‘guix gc --references’ or ‘guix size openmpi’.)

OK, I can send that, though there might still be a case for a separate
runtime output.

>> Looking at the packaging more closely, I think it needs, or should have,
>> various changes.  --enable-static clobbers dynamically-loaded MCA
>> components, which I think is is a non-starter.  One question I have is
>> why are builtin atomics turned on?  They normally aren't, and I don't
>> know what the consequences are.
>
> No idea, you probably know better than me.

I'm afraid not.  It's a question for whoever enabled it.

>> I assume the store is intended to be on a shared filesystem which
>> compute nodes don't duplicate, which helps with space, but I don't think
>> that should be required.  The stateless systems I've set up used a
>> separate compute node image which was much smaller than the login node
>> one by omitting non-runtime rpms.
>
> Yeah the store is typically meant to be shared over NFS or similar.  On
> the topic of setting up Guix on a cluster, you might want to check:
>
>   https://elephly.net/posts/2015-04-17-gnu-guix.html
>   https://hal.inria.fr/hal-01161771/en

I think I've read both of them, and I'd argue with some of what they say
-- but I shouldn't here.

>>> 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))))))
>>
>> Right.
>>
>>> (That said, if the .mod files are compatible among gfortran versions, it
>>> probably doesn’t make sense to do this.)
>>
>> But they're not compatible, which is a real problem
>
> It shouldn’t be a problem if you do something like shown above, then.

It's a general problem that means you have to do something like the
above (which presumably makes the closure big again).

>> By the way, I don't want to be an HPC bigot, but HPC requirements seem
>> to be largely a superset of most others, and applicable in other areas.
>
> Agreed!  And I think Guix also makes it easier to meet some of the HPC
> requirements, from what I’ve seen.

Yes, but there are clear trades-off, and from what I've seen the promise
isn't really realized yet.  I hope it will be, with more engineering
effort, and thanks for all the effort on it.