Add libfabric recipe

[j34ni]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-admin]

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

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory.

_{This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11500410963.}

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

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 (recipes/libfabric/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...

For recipes/libfabric/meta.yaml:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[j34ni]

@minrk Can you want to have a look, please?

[conda-forge-admin]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/libfabric/meta.yaml) and found some lint.

Here's what I've got...

For recipes/libfabric/meta.yaml:

• The test section contained an unexpected subsection name. script is not a valid subsection name.

For recipes/libfabric/meta.yaml:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[conda-forge-admin]

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 (recipes/libfabric/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...

For recipes/libfabric/meta.yaml:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[conda-forge-admin]

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 (recipes/libfabric/meta.yaml) and found it was in an excellent condition.

[j34ni]

@minrk I guess that this is as far as we can go for win and osx until libnl and numactl feedstocks have been updated

Can you do the merge yourself or does it have to be someone different?

[minrk]

I'll not merge it. We can ping the staged-recipes reviewers when it's ready.

But I think we don't quite have numa/libnl working right on linux because of the output:

WARNING (libfabric): run-exports library package conda-forge/linux-64::libnl==3.10.0=h4bc722e_0 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)
WARNING (libfabric): dso library package conda-forge/linux-64::libnuma==2.0.18=h4ab18f5_2 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)

which means they are not linked by libfabric. What features do you expect to result from these, and how could you add them to a test?

For example, I see from the configure output (and I think by omission fi_info --list) that opx uses numa and is unavailable because it is missing uuid.h (add libuuid to host might solve that):

configure: *** Configuring opx provider
checking for opx provider... checking uuid/uuid.h usability... no
checking uuid/uuid.h presence... no
checking for uuid/uuid.h... no
checking numa.h usability... yes
checking numa.h presence... yes
checking for numa.h... yes
configure: looking for library without search path
checking for numa_node_of_cpu in -lnuma... yes
checking rdma/hfi/hfi1_user.h usability... yes
checking rdma/hfi/hfi1_user.h presence... yes
checking for rdma/hfi/hfi1_user.h... yes
checking whether HAVE_ATOMICS is declared... (cached) yes
configure: opx provider: disabled

The only reference I can find to libnl is in usnic, which is not building due to the absence of verbs:

configure: *** Configuring usnic provider
checking for infiniband/verbs.h... (cached) no
configure: usnic provider: disabled

so it would appear that usnic depends on verbs, which is not installed. This is in rdma-core, I believe.

Alternatively, we could start with a totally default build (as we are currently getting in the bundled mpich and openmpi, I believe, so I don't think this is a regression) without libnl and numa on all platforms, and add those on the feedstock. I think that's what this feedstock is actually building now, despite the attempts to link numa/libnl.

Either that, or try adding rdma-core and libuuid to host dependencies, and test with fi_info or another test that the features you expect to be abled by these dependencies are indeed available. This may qualify for a run_test.sh, rather than just test.commands in the recipe.

[j34ni]

@minrk is that any better now?

[minrk]

Making progress, thank you! I have some questions inline about the latest added dependencies and ignore_run_exports.

I think the main remaining thing before this is ready for review is a run_test.sh that verifies the expected components are available. Or if you think the commands are simple enough, they can be in test.commands, but I expect it will be clearer in a run_test.sh.

[minrk]

@conda-forge/help-c-cpp, ready for review!

[j34ni]

@xhochy Thanks Uwe