Bring NativeLibraryConfig.WithLibrary to netstandard2.0 (#960) - #1418
Draft
YoMosa2009 wants to merge 1 commit into
Draft
Bring NativeLibraryConfig.WithLibrary to netstandard2.0 (#960)#1418YoMosa2009 wants to merge 1 commit into
YoMosa2009 wants to merge 1 commit into
Conversation
Expose WithLibrary (and the NativeLibraryConfigContainer overload) on netstandard2.0, not just NET6_0_OR_GREATER. When an explicit path is set, netstandard2.0 now loads that file directly via a small platform-specific P/Invoke shim (LoadLibrary on Windows, dlopen on Linux/macOS) standing in for System.Runtime.InteropServices.NativeLibrary, which isn't available on netstandard2.0. The CUDA/Vulkan/AVX auto-detection backend-selection matrix is left NET6_0_OR_GREATER-only for now, since it depends on System.Runtime.Intrinsics and RuntimeInformation.RuntimeIdentifier, neither of which exist pre-.NET Core 3.0. When WithLibrary isn't called, netstandard2.0 behavior is unchanged from before this commit. Manually verified on Windows via a net48 console harness (forces netstandard2.0 asset selection through a project reference) loading a real system DLL through NativeLibraryConfig.WithLibrary + DryRun, and confirmed the no-explicit-path case still behaves exactly as before. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017JGeTGbj4FKnmWHPGU82yk
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft PR for #960, opening it early so it's easier to review as code instead of me typing paragraphs in the issue.
What this does
NativeLibraryConfig.WithLibrary(path)(and theNativeLibraryConfigContainerversion) now works on netstandard2.0, not just net6.0+. If you call it, netstandard2.0 will load that exact file itself via a small P/Invoke shim (LoadLibraryon Windows,dlopenon Linux/mac) that stands in forSystem.Runtime.InteropServices.NativeLibrary, which doesn't exist on netstandard2.0.If you don't call
WithLibrary, netstandard2.0 behaves exactly like it does onmasterright now, still a no-op,DryRunstill returnsfalsewith anUnknownNativeLibrary. So this is purely additive, no behavior change for anyone not opting in (including Unity's own plugin loader, which this doesn't touch at all).What this deliberately does NOT do
The CUDA/Vulkan/AVX auto-detection backend-selection matrix (
DefaultNativeLibrarySelectingPolicy,NativeLibraryWithCuda/Vulkan/Avx, etc.) stays net6.0+ only for now. Porting that for real means replacingSystem.Runtime.Intrinsics.X86.*/Arm.ArmBaseandRuntimeInformation.RuntimeIdentifier, neither of which exist pre-.NET Core 3.0, and it's a much bigger surface to get right and test. Wanted to scope this PR down to what the issue actually asked for. Happy to tackle that separately if it's wanted.Files touched
NativeLibraryConfig.cs: movedWithLibrary/the library path out of theNET6_0_OR_GREATER-only partial class into the shared one.NativeLibraryUtils.cs: netstandard2.0 branch ofTryLoadLibrarynow checks for an explicit path and loads it if set.PlatformNativeLibrary.cs(new): theLoadLibrary/dlopenshim, only compiled#if !NET6_0_OR_GREATER.UnknownNativeLibrary.cs: doc comment tweak to reflect the new explicit-path case.Testing
LLama.Unittestonly targets net8.0, so it can't exercise the netstandard2.0-only code path directly. I built a throwaway net48 console app (forces netstandard2.0 asset selection through the project reference) and confirmed:WithLibrary(path).DryRun(out lib)actually loads a real Windows DLL and returnsNativeLibraryFromPath.WithLibrarystill gives the old no-op behavior (false/UnknownNativeLibrary/LibraryHasLoadedstaysfalse).I don't have a Linux/macOS box handy to exercise the
dlopenpath, so that part is reviewed but not runtime-tested by me. Flagging that clearly rather than claiming more than I've verified.Open question from the issue thread I'd still like input on: should the explicit-path case also preload
ggml-base/ggmlfrom the same folder like the net6.0 path does (llama.cpp ships split shared libs), or is it fine to assume netstandard2.0/Unity users are pointing at one self-contained binary for now? Went with the simpler version for this PR, easy to add if wanted.Closes/relates to #960.
馃 Generated with Claude Code