library won't find libglfw.so.3.3

[SamHSmith]

On fedora 31 atleast the library won't find the dll. If I manually create a soft link from libglfw.so to libglfw.so.3 the thing works without any issues.
Is this a problem with glfw-net or is there supposed to be a .so link already there?

[SamHSmith]

I belive the reason there isn't a libglfw.so in /lib64 is so that applications can target glfw-2? Anyway glfw-net should change it's search target to look for libglfw.so.3 instead.

[ForeverZer0]

glfw-net does not do any advanced or special searches for resolving the path to the native library, only the standard search paths of the system are used. The soft-link is typically already present with only the base name of the binary as in most *nix systems, though I cannot speak specifically for Fedora.

I do agree that path resolving can definitely be improved, especially with .NET Standard. Mono and .NET Core have some great APIs for dynamically resolving the path, but nothing that is standardized between them. The issue is even worse on Windows, as the binary is named "glfw3", which is inconsistent with its *nix counterparts.

I have a couple solutions I thought to solve this, would be interested in getting some feedback from yourself or others, or something else entirely that I didn't think of.

• Create separate builds for each framework (Framework, Core, Mono) and use their respective API to fine tune dynamically getting the path to the native library

• Simply target .NET Core, as this is going to soon obsolete .NET Framework, and is likely the best and most-used cross-platform .NET runtime (especially in regards to this library)

• Create a custom loader that manually finds the library, depending on the system. This is obviously going to be error prone, and ugly.

• I am not a fan of creating delegates and dynamically loading functions via getting the proc address. This is messy, and there is a performance cost that might not be an issue for most libraries, but I consider graphics and the nature of GLFW to be performance-critical, and not really willing to make that sacrifice.

I am strongly leaning to simply making this .NET Core and taking advantage of its features for loading, especially with its growing maturity.

[SamHSmith]

I'm fully in agreement with you about not using delegates and proc adresses. For my purposes focusing on Core would make the most sense to me. There might be some people who will need to switch their projects over to Core but I don't see someone needing WPF etc and GLFW.

Anyway, if someone does want to stay on Mono or Framework they could always fork the project and and maintain their own version right?