openmpi-* subports, and publishing of binaries

[Christopher Nielsen]

As a follow-up to this thread, I recently noticed that we’ve been publishing binaries for port hwloc for quite some time. And openmpi is utilizing that library, apparently without any issues. (Confirmed by the dependencies of the openmpi-* binaries, via otool.)

So I’m wondering if perhaps there were issues years back, but that’s no longer the case?

It sure would be awesome to publish binaries for openmpi-* ports, as they take quite a while to build.

Thoughts?


> On 2021-02-03-W, at 20:54, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
>> On Feb 3, 2021, at 03:29, Eric Borisch wrote:
>> 
>> This seems off.
>> 
>> Hwloc’s own page talks about the availability of pre-compiled packages, and its demos focus on determining what threads to bind to (on OSes where explicit binding is possible; last I checked it wasn’t on OSX) if you want to maximize or minimize shared resources. (You may want shared L2 cache between threads for cooperative tasks, or to put threads on cores with different memory busses - and bind memory allocs, too - if your code is burning through large, and separable, chunks of memory at max bandwidth.)
>> 
>> It is designed to be used at runtime to provide a uniform (across OSes) way to interrogate the running system’s topology.
>> 
>> This is separate from flags like -march which lock in instruction sets which will be used  — and can create decidedly non-portable binaries.
> 
> You can always ask the committer if he has any further explanation.
> 
> https://github.com/macports/macports-ports/commit/919fd5b27f1ca9c481250203e3dedbac433ecce4
> 
> https://github.com/macports/macports-ports/commit/f803f507183a2f0e92a0c976afd1ec7a1e0ad923
> 
> https://github.com/macports/macports-ports/commit/de413f22fba8d3e348ba6fdd21470505101f3dce