New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libdl is named inconsistently accross Linux distros #2

Open
qmfrederik opened this Issue Oct 11, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@qmfrederik

qmfrederik commented Oct 11, 2017

I was doing some work related to loading native libraries and the realized you already have a project dedicated to that.

Anyway, currently you P/Invoke directly into libdl using its canonical name on libdl. But at least on the Fedora 25 box I'm using at the moment, libdl.so does not exist - only libdl.so.2. And FreeBSD seems to expose dlopen and friends via libc.

@qmfrederik qmfrederik changed the title from libdl is named inconsistent accross Linux distros to libdl is named inconsistently accross Linux distros Oct 11, 2017

@krytarowski

This comment has been minimized.

krytarowski commented Oct 11, 2017

NetBSD ships with dlopen(3) in libc.

@mellinoe

This comment has been minimized.

Owner

mellinoe commented Oct 12, 2017

Hm, well that is a bit frustrating. The obvious solution is to just try a variety of options until one works...

@krytarowski

This comment has been minimized.

krytarowski commented Oct 12, 2017

But at least on the Fedora 25 box I'm using at the moment, libdl.so does not exist - only libdl.so.2.

That part might be about lack of devel libraries (glibc-devel or similar). libdl.so is usually a link to libdl.so.x.y.

FreeBSD and NetBSD ship with dlopen(3) in libc, so no need to detect it. It's good enough to hardcode -ldl for Linux and lack of it for BSDs, these options don't change often, unless someone wants to support HP-UX, IRIX etc..

@MV10

This comment has been minimized.

MV10 commented Aug 20, 2018

For whatever it's worth, libdl resolves properly on OSX but I had to hardcode libdl.so.2 for testing on my Linux VM. Ended up creating a libdl_linux and libdl_osx class and separating the OSes in LibraryLoader... but obviously that would still crash and burn on a Linux that used a non-versioned filename. Quite a mess.

If I'm following the linked corefx discussion, it sounds like the plan is to make the static [DllImport] search more robust for Core 2.2, which will allow this native runtime loading (via Marshal?) work more transparently. Fingers crossed it gets into 2.2... this is too cool to get bogged down by such a stupid quirk!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment