| Summary: | Xcode Archive Strips Vulkan Functions | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Diego <diegoacevedo91> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | NEW --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | amaranth72 |
| Version: | 2.0.9 | ||
| Hardware: | iPhone/iPod touch | ||
| OS: | iOS (All) | ||
| Attachments: | SDL_uikitvulkan.m | ||
|
Description
Diego
2018-11-21 18:01:34 UTC
This has become even more of a problem recently. Perhaps with Xcode 11? After archiving an app and distributing it as bitcode as recommended by Apple, and then rebuilding it from bitcode, vkGetInstanceProcAddr can not be found statically through dlsym. This causes creating a vulkan window to fail. I could not configure the dead code stripping options in Xcode to prevent this from happening. I had to manually edit SDL_uikitvulkan.m to prevent UIKit_Vulkan_LoadLibrary from failing. This allowed me to statically link MoltenVK and rebuild my app from bitcode. It does not incorporate other types of linking. Created attachment 4077 [details]
SDL_uikitvulkan.m
(In reply to Diego from comment #0) > The AppStore does not allow apps with dynamically linked libraries I think dynamically linked libraries have been allowed (with a couple restrictions) since iOS 8. I'm not sure whether MoltenVK or SDL's iOS Vulkan code is set up to take advantage of that, though. Oh, perhaps they do allow it. I've tried several times uploading an app to the AppStore that statically links to libSDL.a and dynamically to libMoltenVK.dylib and I get one of the most unusual errors I've ever seen. A few minutes after the upload completes I get a notification on my iTunes Connect app on my iPhone that says the binary has changed to invalid bundle. What's weird is that's all I get. I don't get an email, and the build doesn't show up anywhere on my iTunes Connect. It just completely disappears with no more information. Although, if I try to upload another build with that same build number, the upload will fail because a build with that number has already been uploaded. There could just be some simple configuration I'm missing to fix this problem but I haven't further looked into it since I usually statically link. Regardless, I don't think dynamically linking should be the solution to this problem. Also, to clarify, the stripping problem I've described in this bug report applies to both linking to libMoltenVK.a and MoltenVK.framework. Neither currently work for me after rebuilding from bitcode, unless I use the modified SDL_uikitvulkan.m I attached. |