Add macOS ARM64 support - #445
Conversation
|
Thanks, code looks clean. This could be a single commit, you can fold them. I'd like to see the build procedure for libvlc arm64 mac though. And it'd be nice to make sure we still support mono and netcore targets, this was an issue when testing #163 |
|
I tried mono and netcore sample and it was failed for another reason. mono just simply throw |
|
It downloads Intel and Apple Silicon variant of VLC, extracts it with 7z, and repackages it as correct structure. nuget-build.webm |
|
that build is GPL also, so you're breaking the license unless your app is opensource. Hence why a proper libvlckit build is needed :) |
|
yeah, my personal project is licensed with GPL so it's fine with it, but it needs to be split as LGPL/GPL variant like Windows if it's gonna actually used. but I think there might be alternative method. |
|
the current vlckit nuget build is static (1 binary), the one from VLC is not (hundreds of plugins). This will break existing users. So lets make a static build of latest vlckit, for both x64 and arm, for 3.x branch, here on github. |
|
or accept the breakage and publish both builds (x64 and arm) as dynamic |
|
I made it work with statically built libvlc with new path scheme. but since this change might introduce real breakage which has possibility to break other OS, it needs more discussion before gets pushed here. (touches library loading) 
|
|
I have no idea about vlckit since it's new for me. I even never tried to build until you said it :( |
|
seems like vlckit already can produce universal binary. it only needs sdk version set to higher one. |
|
|
||
| #if NET5_0_OR_GREATER | ||
| // register custom resolver to load library from discovered path | ||
| NativeLibrary.SetDllImportResolver(Assembly.GetExecutingAssembly(), (dll, _, _) => |
There was a problem hiding this comment.
why make this call right after LoadNativeLibrary succeeded? This looks off.
There was a problem hiding this comment.
to filter out working path. I know it feels off, but when I looked for the P/Invoke exception causes (with inserting debug lines), it was coming from DllImport of LibVLCVersion(), and macOS seems to be have no problem at DlOpen() the LibVLC without path change, but calling any method throws error.
maybe I can add && MAC to condition if you're unsure about it :)
There was a problem hiding this comment.
and this is why I'm calling it "workaround". maybe someone else who has better knowledge at low-level can bring better way to do it
There was a problem hiding this comment.
ok. but first as I said. libvlc build is the initial step.
|
I opened libvlc-nuget PR with static build on mfkl/libvlc-nuget#59. |
2 participants
Description of Change
Added Apple Silicon Mac support as Windows-style path structure.
It still works with current
VideoLAN.LibVLC.Macpackage on x86, but it needs patched package with path structure changed and ARM64 files added to work on Apple Silicon.PoC implementation of libvlc-nuget is available on AnthonyKwon/libvlc-nuget. (It's not ready to be upstreamed yet as it uses hacky method to package)
Issues Resolved
API Changes
internal const string ArchitectureNames.MacOSArm64inConstants.csPlatforms Affected
Behavioral/Visual Changes
None
Before/After Screenshots
Not applicable
Testing Procedure
net9.0-macosandnet10.0-macosfromTargetFrameworkand build only with Xcode needed.Since you're going to test only with macOS target, other targets are not needed to be tested.
I used this method for testing since I was unable to successfully build on some mobile platform. (seems not relevant with these changes since I was not even able to build pure LibVLCSharp)
build.webm
PR Checklist