C#•4w ago

Updating loading mechanism of native libdl in OpenGL.NET

Hi there 👋🏼 I am trying to get the Nu engine to run. It depends on OpenGL.NET, which is written in C#. I am a F# developer myself, so please consider that in contrast to my obvious ignorance. 😄 So: First, we have to understand that .NET 8 changed the way they load native libraries. Great, since it's now abstracted across platforms. However, I am new to C#, and the API documentation lets me a bit in the dark. Probably just me. So, API documentation. This is the code in question:

#if NETCORE

    [DllImport("dl")]
    public static extern IntPtr dlopen(string filename, int flags);

    [DllImport("dl")]
    public static extern IntPtr dlsym(IntPtr handle, string symbol);

#else

    [DllImport("dl")]
    public static extern IntPtr dlopen([MarshalAs(UnmanagedType.LPTStr)] string filename, int flags);

    [DllImport("dl")]
    public static extern IntPtr dlsym(IntPtr handle, [MarshalAs(UnmanagedType.LPTStr)] string symbol);

#endif

    [DllImport("dl")]
    public static extern string dlerror();    }

#if NETCORE

    [DllImport("dl")]
    public static extern IntPtr dlopen(string filename, int flags);

    [DllImport("dl")]
    public static extern IntPtr dlsym(IntPtr handle, string symbol);

#else

    [DllImport("dl")]
    public static extern IntPtr dlopen([MarshalAs(UnmanagedType.LPTStr)] string filename, int flags);

    [DllImport("dl")]
    public static extern IntPtr dlsym(IntPtr handle, [MarshalAs(UnmanagedType.LPTStr)] string symbol);

#endif

    [DllImport("dl")]
    public static extern string dlerror();    }

Here on Github. Now my question number 1: I am confused about the libraryPath. Lots of distros, and macOS as well, seem to have different paths. And question number 2, if somebody wants to be particularly nice to me: Could you show me how to use the syntax? 🥺 Is it just public static IntPtr Load(string libdl.so.2); without an attribute?

60 Replies

ShalokShalom 🌱 🌏OP•4w ago

Ah, I guess libraryPath means just the executable name, that is on the PATH. That could be worded better. ^^

qqdev•4w ago

Any reason why you want to use that specific engine? You could also just hop on the Unity train if you want to make games

Unknown User•4w ago

Message Not Public

qqdev•4w ago

Godot is also quite nice, true Enjoyed it

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

nope trying to build

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

The original maintainer is on Windows, so he didnt notice it doesnt build on Linux for close to 2 years already 😄 Thats the only way, that is currently supported

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I also thought about providing a ReadyToRun for everyone. Thats not my code. 🙂 thats just the OpenGL binding to dotnet

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I have absolutely no idea, sorry. :shrugs:

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I assume its just a remicent from the past, but idk how they managed the runtimes

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

? The code you are looking at, is not from the maintainer of the engine.

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

no, its just the maintainer of OpenGL.NET ^^ no, its that one from the Github link below it

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

If you say so, yes.

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

Yes I havent thought about it like that before ^^ thats all

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

wonderful 😄

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

DllImport is, as far as I understand, deprecated. At least in this context. .NET 8 introduced a change, how it is supposed to load libdl

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

They changed the name they are expecting from libdl to libdl.so.2 and the link above shows you, that its expected to use the new API to load libraries like that.

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

See the links in the original question please

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

We have time 🙂

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I can wait, thanks a lot for your helpful attitude 🙂

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

yep, thats what I was asking

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

😁 https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary.load?view=net-9.0 that would be amazing

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I would like to know the difference between the two APIs That is, NativeLibrary.SetDllImportResolver and NativeLibrary.Load

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

All good 🙂

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I would avoid that, as F# code is probably not compatible with it.

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

SourceGen from C# is generally an anti-pattern for us, as its breaking the CIL compatability. Yeah, I guess I could do that. I may just wait for somebody who knows this stuff.

Unknown User•4w ago

Message Not Public

reflectronic•4w ago

can you explain what is the issue? like, what exactly is not working this is that there is no libdl.so on your computer?

Unknown User•4w ago

Message Not Public

wasabi•4w ago

libdl was removed in recent glibcs. ... if that's the question There's a symlink from... libdl.so.2 i think. But not from libdl.so itself. If you're asking how to write perfect cross platform loading code, that works on the major three (linux, mac, windows), and also core, mono and framework, then that's hard and a lot of ifs. You have to use different techniques for each. libdl.so.2 btw only exists for backwards compat. Dlopen, dlsym, etc, are directly in libc now In fact what you're trying to do here looks pretty close to what I have on libikvm Though I just gave up trying to do it correctly from .net and exported my own dlopen from my own library. Believe because of OSX.

Unknown User•4w ago

Message Not Public

ShalokShalom 🌱 🌏OP•4w ago

I dont care about Mono and Framework. How about https://github.com/dotnet/dotnet-docker/discussions/4938#discussioncomment-9157604

wasabi•4w ago

You might not. But I assume OpenGL.NET does. OpenGL.Net is running on a number of .NET frameworks: .NET Framework 3.5 .NET Framework 4.6.1 Xamarin/Android .NET Core 1.1 .NET Core 2.0 .NET Standard 2.0/1.4/1.1 (under development) I don't know what you are asking about with that link.

ShalokShalom 🌱 🌏OP•4w ago

Well, I am fine if OpenGL.NET does not run after this on anything else than current .NET And the link describes a slightly different solution, than what you suggest?

wasabi•4w ago

Probably to appropriately fix OpenGL.NET, if it needs it. I haven't yet figured out what is broken with it. So, looking at GetProcAddressOS in Khronos.Net, it looks like it tries to DllImport 'dl'. Yeah, that's not the correct way to do it on modern Linux. The correct way is to obtain it from 'c'. But that change occurred in glibc 2.34. So I'd check with OpenGL.NET if they intend to support Linux versions before that. If not, then a PR to fix the dlopen/sym functions to come from 'c' would be fine. But I'd also check to see if they support non-glibc. And then figure out where dl* is in that. Because I forget. Looks like it's also libc on MUSL. But it might be libdl still on Bionic. So I'd check on that. If they intend to support those other versions, then, looking at their code, they have an abstraction around this: GetProcAddress. You could implement a special version for each of the various things, and return that appropriately just like they do now for Windows/Linux/OSX. Put that into a PR. Congratulate yourself. Etc.

ShalokShalom 🌱 🌏OP•4w ago

The library seems pretty unmaintained. There is no commit in the last 11 months, and issues stay unanswered. So I am completely fine, doing that in a way, that only pleases me - and glibc sounds fine. Nu - the game engine - is probably rarely used on Alpine Linux, and co. 🙂 I am also fine with supporting only newer Linux distros. How do you mean, I can take it from C? How exactly do I do that?

wasabi•4w ago

libc

ShalokShalom 🌱 🌏OP•4w ago

Ah, so I simply swap dl for libc, I will see that tomorrow Thanks!

wasabi•4w ago

https://lwn.net/Articles/864920/

LWN.net

GNU C Library 2.34 released

Version 2.34 of the GNU C library has been released. Significant changes include the folding o [...]

wasabi•4w ago

NEWS for version 2.34 ===================== Major new features: * In order to support smoother in-place-upgrades and to simplify the implementation of the runtime all functionality formerly implemented in the libraries libpthread, libdl, libutil, libanl has been integrated into libc. New applications do not need to link with -lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility, empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are provided, so that the linker options keep working. Applications which have been linked against glibc 2.33 or earlier continue to load the corresponding shared objects (which are now empty). The integration of those libraries into libc means that additional symbols become available by default. This can cause applications that contain weak references to take unexpected code paths that would only have been used in previous glibc versions when e.g. preloading libpthread.so.0, potentially exposing application bugs.

Gaming

Programming

Updating loading mechanism of native libdl in OpenGL.NET

Did you find this page helpful?