LibVLC loading refactoring for macOS
Problem to solve
To be able to use libvlc builds from official releases, we need to be able to load and P/Invoke dynamic libvlc macOS builds.
Currently, it's all statically linked together in a libvlc.dylib
binary. The libvlc builds from vlc.dmg are organized similarly to the libvlc windows ones (plugins folder, lib folder, share folder).
Intended users
macOS users.
Proposal
There are a few challenges...
- We need to perform this refactoring while not breaking existing platforms (netcore and mono).
- We need to perform this refactoring while keeping the current platform versions number supported (i.e. any netcore version).
mono/cocoa support is fine, issue is with netcore.
Problems are two fold:
- To be able to re-use the current P/Invoke code, we need to keep the dllimport statements as they are currently. In theory, one could load manually the dylib, and all further dllimport calls would look at the currently loaded dynamic librairies before trying a new dlopen to perform the dlsym. That's the theory anyway https://github.com/libgit2/libgit2sharp/blob/7fc4be5193dbdd08538b4b150332b5a73770e0f6/LibGit2Sharp/Core/NativeMethods.cs#L40
However, that's not what I observe. And for the netstandard/netcore build, that means the dlopen call argument is different on mac and windows (@rpath/libvlc
/libvlc
) and it should not.
- Even when using the non standard
@rpath/libvlc
dlopen argument and setting the correctVLC_PLUGIN_PATH
,libvlc_new
returns null.
https://github.com/mfkl/libvlcsharp/commits/mac-libvlc-loading
https://github.com/mfkl/libvlc-nuget/blob/mac-loading-rework/build/VideoLAN.LibVLC.Mac.targets
Documentation
Just the cherrypicking enabling whenever this works.