Add forced resigning of SDL2 outputs after stripping #2174
Conversation
|
Looks fine in principle, but I think we need to extend the change to all our other native build scripts where we do stripping. So that'd be Assimp, GLFW, OpenAL Soft, SwiftShader, and Vulkan Loader. They all invoke We potentially also need to change SPIR-V Cross, SPIR-V Reflect, and Shaderc -- they're built differently -- but would need to check that the currently-shipped binaries have valid ad-hoc signatures. |
|
I'll give that a go :) |
|
All the ones you mentioned have a correct signature. They all have -arm64 and -x64 libraries, not using lipo. or SDL needs to be aligned with all the others by not LIPOing it at all and keeping two separate binaries. That also then sticks to the osx-arm64 convention used in all other packages, |
|
I would personally prefer if we switched to thin binaries since that results in smaller RID-specific deployments. When a user does SDL and MoltenVK are the only libraries that we ship fat binaries for, and AFAICT, MoltenVK is only done that way because its Xcode project files are set up to only produce fat binaries for macOS (desktop). |
|
I checked out the test build you made: this one verifies for me |
|
I think thin binaries might be better in general. Most macOS releases will ship with both for sure though. Splitting this up for SDL is I think a bit above me. But I do see that it now uses lipo to join them... so not doing it gives you separate ones? It probably needs more changes in config |
|
Am I correct in assuming that dotnet can’t publish a universal osx distribution today anyway? If so then yeah it makes sense to thin it out. |
That's my impression. I also previously talked to @agocke on Discord about our (and some other projects's) use of So, even if we stick to fat binaries (as we probably would for MoltenVK specifically), we should probably stop relying on the |
|
Isn’t it documented here? The NuGet side I’d imagine has the same level of documentation most obscure NuGet features have indeed. How similar to Xamarin is net8.0-mac wrt distribution and build? Can that produce fat bundles? If so, then I recommend keeping the fat binary. Otherwise, go thin all the way, including for MoltenVK as it makes sense to be consistent across the library. net8.0-ios obviously produces fat bundles so I recommend staying fat here. |
I hadn't noticed the explanation in the RID graph section. That would seem to change the calculus here. @agocke can you weigh in on this?
I think the question we should be asking, both for macOS and iOS (etc), is: Given thin binaries for each arch and a configuration to produce a fat bundle, can the tooling produce fat binaries? (I.e. do the Regarding MoltenVK, the issue there is that their build system always produces fat binaries AFAICT. But maybe we can just |
|
I don't believe any of the dotnet tooling has support for implicitly fattening today (which I agree would be awesome), or at least I don't remember this being something Xamarin could do and I doubt the team have had bandwidth to expand upon that. |
The architecture-less RIDs are intended for things that have platform dependency, but not architecture dependency, like managed assets that only work on one OS, or plain files that are only relevant for one OS. We didn't really intend to load native assets from those directories -- but the system doesn't prohibit it either. It doesn't necessarily seem like something we'd break, so I wouldn't suggest you remove it immediately. This is more of a warning that we didn't really design with this use case in mind. |
|
Ok, maybe we just maintain status quo then, and go with this PR as-is.
Just for good measure, would you mind checking MoltenVK as well? |
|
So to summarize:
I think the most logical seems to move away from the universal binaries here. SDL is Lipo-joining them, so avoiding that already would solve it there. (as opposed to what this PR now does, which is fix the code sign). |
This comment was marked as outdated.
This comment was marked as outdated.
|
Actually, disregard that previous comment. It seems there's no official support for universal apps: dotnet/sdk#33469 I don't know if this extends to mobile targets? |
MoltenVK is fine. Also not using lipo there, nor strip. |
|
Also checked tvOS, which is a static library, universal for arm64 and arm64e. Not code-signed (as this does not make sense for static libs). |
|
@alexrp Building a macOS universal app is still supported today: // In Program.cs
CoreFoundation.OSLog.Default.Log("hi"); // needed because linker errors pop up otherwise<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0-macos</TargetFramework>
<OutputType>Exe</OutputType>
<Nullable>enable</Nullable>
<ImplicitUsings>true</ImplicitUsings>
<RuntimeIdentifiers>osx-x64;osx-arm64</RuntimeIdentifiers>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<ApplicationId>com.companyname.MacCatalystApp1</ApplicationId>
<TrimMode>full</TrimMode>
<SupportedOSPlatformVersion>11.0</SupportedOSPlatformVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Silk.NET.SDL" Version="2.21.0" />
</ItemGroup>
<ItemGroup>
<SilkExternalPInvoke Include="Silk.NET.SDL.Sdl" />
</ItemGroup>
</Project> |
|
Given the above and also that by virtue of supporting NS20 we still technically support older Xamarin use cases even though we've been explicit about our opinions here in our blog, we should probably #StayFat. |
|
Sheesh, would be nice if there was actually some authoritative (or findable, at least) documentation on this stuff. There's so much conflicting information floating around. |
* Add forced resigning of SDL2 outputs after stripping * Update SDL2 binaries (#2175) * New binaries for SDL2 on Microsoft Windows 10.0.20348 * New binaries for SDL2 on Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:50 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_VMAPPLE * New binaries for SDL2 on Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:50 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_VMAPPLE * New binaries for SDL2 on Microsoft Windows 10.0.20348 --------- Co-authored-by: The Silk.NET Automaton <[email protected]> --------- Co-authored-by: Jos Kuijpers <[email protected]> Co-authored-by: silkdotnet <[email protected]> Co-authored-by: The Silk.NET Automaton <[email protected]>
This PR changes the SDL2 build to code-sign at the very end, fixing #2174. The build indicated:
On Mx systems, all binaries need a valid signature.
The build now adds a code sign, and has a new message:
libSDL2-2.0.dylib: replacing existing signature