Skip to content
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

Versioning and loading libraries #4032

Closed
stephentoub opened this issue Mar 14, 2015 · 7 comments
Closed

Versioning and loading libraries #4032

stephentoub opened this issue Mar 14, 2015 · 7 comments

Comments

@stephentoub
Copy link
Member

As discussed in dotnet/coreclr#441, we are currently brittle with regards to our usage of dlopen, which requires that we provide the name of a library that includes version information. We need to figure out how we want to handle this, for the specific case discussed in dotnet/coreclr#441, for DllImports in general, and for anywhere else we may rely on loading arbitrary libraries.

@Tragetaschen
Copy link
Contributor

FWIW, that's already a common grief for users of aspnet/KestrelHttpServer on Linux, so it would be great if this becomes a general solution that is available for all packages outside.

Usually, you use something like pkg-config to learn about the installed library version when building from source and calling the C-linker.

Mono uses <dllmap/> in global and application specific config files to translate between a library name on a DllImport and the versioned library name like libc -> libc.so.6. The global /etc/mono/config is distribution-specific and filled when mono is built for that distribution.

@akoeplinger
Copy link
Member

As @Tragetaschen said, this is a common problem and Mono's solution to this is dllmap as described here.

While browsing the net, I found that Julia also has an interesting approach: they provide an api that internally reads the output of /sbin/ldconfig -p and creates a map of all the libraries, e.g.:

$ /sbin/ldconfig -p | grep libcrypto
    libcrypto.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0

... which means one can just call the wrapper function with the "simple" module name and get back the proper name incl. version.

@kangaroo
Copy link
Contributor

The Julia approach seems particularly nice, I've never liked having to ship dllmaps, they're a pain and confusing for users.

@natemcmaster
Copy link
Contributor

I also agree that dllMaps are ugly, but it would be good to have a general solution for per-platform library names.

Adding to Kestrel user's grief: trying to get Microsoft.Data.Sqlite to load native sqlite calls is pain because DllImportAttribute requires a constant library name. On Windows it's "sqlite3" and OS X and *nix it's "libsqlite3".

@bricelam
Copy link
Contributor

Please, please, please build on all the great work of Mono.

@jeffschwMSFT
Copy link
Member

dotnet/coreclr#19373

@swaroop-sridhar
Copy link
Contributor

Closing this issue, the matter is tracked by dotnet/corefx#32015.

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants