Ludovic Courtès 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,
Hello Dave,
Dave Love skribis:
> Ludovic Courtès writes:
[...]
>> 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.
>
> I think I was misunderstanding. Is the intention actually to get rid of
> dependencies o
Ludovic Courtès writes:
> Hi,
>
> Dave Love skribis:
>
>> Ludovic Courtès 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
>> basic
Hi,
Dave Love skribis:
> Ludovic Courtès 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 pac
Ludovic Courtès 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 developme
Hello,
Open MPI retains references to GCC, GFortran, etc., which significantly
increases its closure 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
