We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4397 - Xcode Archive Strips Vulkan Functions
Summary: Xcode Archive Strips Vulkan Functions
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.9
Hardware: iPhone/iPod touch iOS (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-21 18:01 UTC by Diego
Modified: 2019-12-02 16:55 UTC (History)
1 user (show)

See Also:

Attachments
SDL_uikitvulkan.m (8.66 KB, text/x-csrc)
2019-11-30 16:02 UTC, Diego 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Diego 2018-11-21 18:01:34 UTC 
The AppStore does not allow apps with dynamically linked libraries, so MoltenVK must be statically linked. 
When archiving a project, Xcode natively strips dead code (or at least strips more dead code than if building for debug or release). If MoltenVk is statically linked then SDL_Vulkan_LoadLibrary is never able to find vkGetInstanceProcAddr, since there's no actual link to it. Xcode has build settings to turn off stripping but I don't believe that should be the solution to this problem. I think SDL for iOS should have some hard references to it's used vulkan functions.
Comment 1 Diego 2019-11-30 16:01:21 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.
Comment 2 Diego 2019-11-30 16:02:18 UTC 
Created attachment 4077 [details]
SDL_uikitvulkan.m
Comment 3 Alex Szpakowski 2019-12-01 19:28:03 UTC 
(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.
Comment 4 Diego 2019-12-02 16:55:53 UTC 
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.