openmpi v5.0.5

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• [ ] Dependencies have been updated if changed: see upstream
• [ ] Tests have passed
• [ ] Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with code>@conda-forge-admin,</codeplease add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name	Upstream Version	Current Version
openmpi	5.0.5

Dependency Analysis

We couldn't run dependency analysis due to an internal error in the bot, depfinder, or grayskull. :/ Help is very welcome!

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by - please use this URL for debugging.}

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[minrk]

Yeah, I guess. I'm also not 100% sure this matters. If $LDFLAGS are respected in conda-forge packages, then --disable-new-dtags will also be given after the enable embedded in the wrapper, so disable will have higher priority, I think. So anything built with mpicc in conda-forge still does not use new dtags, I think, even with this in the wrapper.

[dalcinl]

On a somewhat related matter, why are we setting wrapper_ldflags='-Wl,--allow-shlib-undefined' in compiler wrappers? Isn't that flag something that conda-forge should add globally to LDFLAGS?

[minrk]

the shlib-undefined is related to user runtime compilation and conda-forge's weighed-down default sysroot to older than the one used to build openmpi (not technically the case anymore as of this month). Discussion is in #143 (especially here). Essentially, package compilation is expected to use $LDFLAGS, but I don't think user runtime compilation necessarily should. So the wrappers should include whatever flags are necessary for compilation to basically function, as opposed to doing the opinionated 'right thing' for building a conda-forge package, and allow-shlib-undefined is required for mpicc to basically function by default in a default environment.

I don't believe preferring old sysroot for user environments is the right move, and hope it will stop happening soon after the c_stdlib migration completes, but for now allow-shlib-undefined in the wrapper is a practical choice such that mpicc can work at all by default.

160 is an alternative, stricter path to a similar result: don't allow openmpi to be installed in an env with older sysroot. This doesn't affect conda-build packages, because sysroot and openmpi don't tend to be in the same env (cross compilation notwithstanding). The downside to #160 is it actually forces downstream packages (if they cross compile, at least) to use the same or greater sysroot, when that's not actually required. So it's perhaps an improvement for runtime compilation for users and a tedious annoyance for packagers. I still don't know if that's a positive tradeoff or not. But --allow-shlib-undefined always works, while pinning sysroot adds unconditional extra work for downstream package maintainers if the default sysroot is older, because it actually does work fine (thanks to --allow-shlib-undefined).

[dalcinl]

@minrk All good then , please merge at your earliest convenience, then I can move to PETSc.