Unable to load native libraries

[mdelz]

Hi 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

Silk.NET/src/Core/Silk.NET.Core/Loader/DefaultPathResolver.cs

Line 203 in 36f3130

private bool TryLocateNativeAssetInRuntimesFolder(string name, string baseFolder, out string result)

        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;
        }

[Perksey]

This is unlikely to be our bug. Can you try deleting bin/Debug/net6.0/runtimes/ and rebuild?

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.

Yep that's exactly the cause.

[mdelz]

Yes that solves the build issue, but I am still unable to open a window.

Unhandled exception. Silk.NET.Core.Loader.SymbolLoadingException: Native symbol not found (Symbol: glfwWindowHintString)
   at Silk.NET.Core.Loader.LibraryLoader.ThrowSymbolLoading(String functionName)
   at Silk.NET.Core.Loader.LibraryLoader.LoadFunctionPointer(IntPtr handle, String functionName)
   at Silk.NET.Core.Loader.UnmanagedLibrary.LoadFunction(String name)
   at Silk.NET.Core.Contexts.DefaultNativeContext.GetProcAddress(String proc, Nullable`1 slot)
   at Silk.NET.GLFW.Glfw._B.get__U()
   at Silk.NET.GLFW.Glfw.WindowHintString(Int32 hint, String value)
   at Silk.NET.Windowing.Glfw.GlfwWindow.CoreInitialize(WindowOptions opts)
   at Silk.NET.Windowing.Internals.WindowImplementationBase.CoreInitialize(ViewOptions opts)
   at Silk.NET.Windowing.Internals.ViewImplementationBase.Initialize()
   at Silk.NET.Windowing.WindowExtensions.Run(IView view)

[Perksey]

Given you're on Linux, ensure you have GLFW 3.3 installed. glfwWindowHintString was added in GLFW 3.3

[mdelz]

Thanks for that tip. By default Ubuntu installs version 3.2.1, I found a working GLFW 3.3 version here https://launchpad.net/ubuntu/+source/glfw3/3.3.2-1/+build/18625810

One more stupid question, why do I have to install it if your library comes with pre-built binaries?

[Perksey]

One more stupid question, why do I have to install it if your library comes with pre-built binaries?

We only use our pre-built ones as a fallback, we'd prefer to use whatever the user gives us where possible. If we used our pre-built binaries by default, some users would complain that their custom, potentially newer GLFW doesn't get loaded by silk. We figured avoiding the pre-builts if the user has something else in their environment is the lesser of two evils.

Hopefully updating GLFW on your system will solve your issue!

[mdelz]

It would be great if there would be a config option to load the pre-built binaries. Maybe also combined with a check if the system installed binary has the correct version.

End-users might not know how to install the correct binaries if they have an outdated version installed.

[Perksey]

Will add this in 2.15, will use this issue to track. Thanks for the suggestion!

[Perksey]

In 2.15 you will be able to do something like

if (PathResolver.Default is DefaultPathResolver pr)
{
    pr.Resolvers = new()
    {
        DefaultPathResolver.PassthroughResolver,
        DefaultPathResolver.LinuxVersioningResolver,
        DefaultPathResolver.MacVersioningResolver,
        DefaultPathResolver.BaseDirectoryResolver,
        DefaultPathResolver.MainModuleDirectoryResolver,
        DefaultPathResolver.RuntimesFolderResolver,
        DefaultPathResolver.NativePackageResolver
    };
}

Or, to address your issue (the above is just default):

if (PathResolver.Default is DefaultPathResolver pr)
{
    pr.Resolvers = new()
    {
        DefaultPathResolver.NativePackageResolver, // <-- first, look in the native packages for an exact match
        DefaultPathResolver.BaseDirectoryResolver, // <-- if there's no match, look in AppContext.BaseDirectory for an exact match
        DefaultPathResolver.MainModuleDirectoryResolver, // <-- if there's no match, look in Path.GetDirectoryName(Process.GetEntryAssembly().MainModule.FileName) for an exact match 
        DefaultPathResolver.RuntimesFolderResolver, // <-- if there's no match, look in the runtimes folder for an exact match
        DefaultPathResolver.LinuxVersioningResolver, // <-- as a fallback, do a regular LD_LIBRARY_PATH search for any matching version
        DefaultPathResolver.MacVersioningResolver,
    };
}

[Perksey]

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.