Unable to load native libraries
See original GitHub issueHi everyone,
I was debugging why my application is not able to find glfwWindowHintString
after updating from silk 1.9 to 2.14
It looks like that DefaultPathResolver.TryLocateNativeAssetInRuntimesFolder
appends the name of the library twice.
Expected file to load: bin/Debug/net6.0/runtimes/linux-x64/native/libglfw.so.3
File it tries to load: bin/Debug/net6.0/runtimes/linux-x64/native/libglfw.so.3/libglfw.so.3
I cannot properly debug if this is the root of my problem because moving the file int the directory it expects results in the following build error.
Microsoft.Common.CurrentVersion.targets(4808, 5): [MSB3024] Could not copy the file "~/.nuget/packages/ultz.native.glfw/3.3.3.1/runtimes/linux-x64/native/libglfw.so.3" to the destination file "bin/Debug/net6.0/runtimes/linux-x64/native/libglfw.so.3", because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles.
OS: Ubuntu 18.04 .Net: net6.0
private bool TryLocateNativeAssetInRuntimesFolder(string name, string baseFolder, out string result)
{
static bool Check(string name, string ridFolder, out string result)
{
var theoreticalFName = Path.Combine(ridFolder, name);
if (File.Exists(theoreticalFName))
{
result = theoreticalFName;
return true;
}
result = null;
return false;
}
foreach (var rid in GetAllRuntimeIds(RuntimeEnvironment.GetRuntimeIdentifier(), DependencyContext.Default))
{
if (Check(name, Path.Combine(baseFolder, "runtimes", rid, "native", name), out result))
{
return true;
}
}
result = null;
return false;
}
Issue Analytics
- State:
- Created a year ago
- Comments:9 (6 by maintainers)
Top GitHub Comments
Will add this in 2.15, will use this issue to track. Thanks for the suggestion!
Note that the new API is intentionally not very accessible, as realistically you probably shouldn’t need to use hacks like this. Especially when doing a release using
dotnet publish -c Release -r linux-x64
, the correct binary gets put by your executable anyway which I believe libdl will look at first.