ci/mingw64-fat: add FAT mingw64 builds - #17526
Conversation
|
|
||
| VkInstance inst = vk->vkinst->instance; | ||
| VkResult res = vkCreateWin32SurfaceKHR(inst, &wininfo, NULL, &vk->surface); | ||
| mp_assert(vk->vkinst->get_proc_addr); |
There was a problem hiding this comment.
is depending on the upstream vulkan loader that bad? 馃
There was a problem hiding this comment.
Upstream Vulkan loader doesn't support static linking. That's why all our (other) packages have vulkan-1.dll in them. Apparently https://github.com/BtbN/Vulkan-Shim-Loader exists to workaround that. But it doesn't load functions from platform specific xmls. While, it could be fixed there, I don't mind loading it through get_proc_addr.
There was a problem hiding this comment.
ah this is a static build? dynamic is nicer IMO
There was a problem hiding this comment.
Why can't it just link to vulkan dll? Windows now includes vulkan loader.
There was a problem hiding this comment.
ah this is a static build? dynamic is nicer IMO
This build has probably over 100 libraries linked (I didn't even count, it's everything), linking it statically just makes the output cleaner, we don't need anything else to interact with those dlls.
Why can't it just link to vulkan dll? Windows now includes vulkan loader.
It's on graphic driver, and on some systems in might not be available. Either way, it's up to docker image that I use. I think it's cleaner to dynamically load vulkan dll. We should be doing it in fact and not directly link to loader.
There was a problem hiding this comment.
ah this is a static build? dynamic is nicer IMO
What makes dynamic mpv Windows compiles nicer for you? Legit question.
There was a problem hiding this comment.
dynamic causes less weird build issues, that's all.
There was a problem hiding this comment.
Dynamic linking on MinGW only introduces more problems, like auto import and runtime pseudo relocation.
d89ef3e to
c34cc81
Compare
|
@sfan5 @Dudemanguy @avih: Do you have option how to finalize this PR? The current state is ok, to produce artifacts, in the off chance it duplicates some code. Some idea, I could see.
|
To avoid conflicts with xavs2.
https://github.com/BtbN/Vulkan-Shim-Loader doesn't expose those symbols, so just load them manually.
Build mpv and libmpv inside the FFmpeg-Builds container images, which ship a mingw-w64 cross toolchain and every FFmpeg dependency as a static library. FFmpeg itself, LuaJIT, subrandr and the C++/WinRT projection are built on top. One day we might fork the FFmpeg-Builds and do mpv-Builds, but the overhead of maintaining that is bigger than current cost of building few deps on top. x86_64 and aarch64 are built in the GPL and the LGPL variant. The GPL variant publishes mpv.exe, both variants publish a libmpv package with the DLL, its import library and the headers. rav1e and librsvg are Rust libraries with their own copy of the Rust standard library, which collides with subrandr's at link time, so both are left out of FFmpeg for now.
Attach the full x86_64 and aarch64 builds instead of the shared x86_64 mingw-w64 build, which they supersede. The i686 build stays, it exists only as the shared build. Add a libmpv section with the GPL and LGPL packages, label every entry by architecture and flavour.
Run the build workflow for v0.* tags and let the publish job upload the artifacts to the release of that tag, with the run id stripped from the asset names to match the previous hand-made uploads. The release is created as a draft when it does not exist yet, so the notes can be filled in before publishing.
4 participants
More complete mpv builds. Also provide libmpv in both gpl and lgpl
variant.