Post

Replies

Boosts

Views

Activity

Multiple Executables in a Single Bundle Fails to Launch Others After Codesign
We have a rather complex network of dependencies for our application stack and, from it, we create multiple unique executables that are placed into the Contents/MacOS directory of our bundle. MyApp.app `- Contents/ `- Frameworks/... `- MacOS/ `- exec_a `- exec_b `- Resources/... Both executables require the same dependencies (and use the same shared .dylib files built as targets in the same project) so it makes sense for them to be in the same place rather than in their own .app folder as I understand it. Qt Libs -> core_lib.dylib -> gui_lib.dylib -> exec_a `-> exec_b etc. We've confirmed build artifacts are correct and the rpath/dependencies are all clean. When in development, all executables run as expected and we can command exec_a (the executable we're listing in the primary Info.plist) to launch exec_b at any time. Once the bundle is signed, however, we cannot get exec_b to launch in any capacity. Even lldb dies right away because it can't attach to anything. We assume this is something in the gatekeeper area of blocking these additional executables. We get the following when trying to run those additional exes in any way: Trace/BPT trap: 5 We're using macdeployqt to finalize the bundle and bring in the correct packages - perhaps something it's doing is causing the additional executables to fail or we're missing an entitlement. We've submitted the app to TestFlights successfully even with these invalid executables to see if there was something the processing of the app would find but so far nothing. We've seen other example of applications with multiple executables in the same MacOS directory and are wondering what the difference is. Any hints or guidance would be great. Thank you!
6
0
86
3w
Xcode 16 Crash While Validating (com.apple.root.default-qos)
Hello, We're attempting to validate our application archive through Xcode but the application is crashing during the validate step and we're not sure why. Platform: macOS 15.1 Arch: arm64 We've confirmed that our developer agreements are up to date (a suggestion made by other posts on these forums). Other suggestions have been to downgrade Xcode but we're hoping there's another explanation. The application is quite complex - many libraries and framework - but executes as expected during development and testing. Crash Report Any insight into this error would be appreciated. We're sure it's something wrong with our plist or archive structure but the crash is limiting our ability to debug.
5
0
323
Mar ’25