msquic depends on libnuma but packages don't state that

[wfurt]

Describe the bug

This is similar to #2975 and it seems to be new in 2.2

$ ldd artifacts/bin/linux/x64_Debug_openssl/libmsquic.so.2.1.7
	linux-vdso.so.1 (0x00007ffd7b1c4000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc7fa425000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc7fa402000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7fa210000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc7fa7aa000)
$ ldd artifacts/bin/linux/x64_Debug_openssl/libmsquic.so.2.2.0
	linux-vdso.so.1 (0x00007ffcb51bf000)
	libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f0d22fd8000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0d22fd2000)
	libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f0d22fc5000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0d22fa2000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0d22db0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f0d23423000)

The consequence is that it

1. can break uses on upgrade as new library needs more than the previous version
2. allows to install msquic package without warning but leave it dysfunctional.

that is unpleasant and difficult for users to diagnose.

Affected OS

• Windows
• Linux
• macOS
• Other (specify below)

Additional OS information

No response

MsQuic version

main

Steps taken to reproduce bug

easiest is to run ldd to show library dependencies.

Expected behavior

packages properly state dependencies

Actual outcome

libnuma is missing

Additional details

We should either fix packages to pull in libnuma as needed or we should make it soft dependency e.g. optionally use it via function pointers.

cc: @ManickaP @CarnaViire

[nibanks]

Do we need to explicitly declare dependencies on every library you dumped above?

[wfurt]

I don't think so. I would assume all the libc and linker are given. We can explore if other packages declare libpthread. I think it is probably part of libc as well.

[nibanks]

I believe we got the code to not require libnuma, but numa support just lights up if it is installed. Can we make it a fixed dependency? Is it expected to be available on all platforms we want to support?

[wfurt]

I don't understand what "fixed dependency" means. msquic can be configured in different ways. The published package dependencies should reflect the chosen set for given binary. We do not need to do that if the is light-up e.g. base functionality is there.

cc: @CarnaViire @ManickaP

[ManickaP]

I think optional dependency might be a good solution for libnuma. WDYT?
And do we have test coverage for both options: with and without? Should we also test, at least once manually, all 4 combinations (build with/without, installed with/without) for expected outcomes?

[ManickaP]

This needs to get fixed before we release .NET 8. How come it surfaced in: dotnet/runtime#87038 ??? What I understood from @nibanks comment: #3421 (comment) is that the dependency is optional and the code knows how to work without libnuma present, regardless where/how it was build.