I just noticed that libclang_rt.asan_osx_dynamic.dylib is in the release build of my macOS app’s Contents/Frameworks/ directory. I was under the impression that the address sanitizer is a debug feature, so I was surprised to see this. I’m using xcodebuild in a custom build script to generate the release build of the app.
2 questions:
- Is it wrong for that dylib to be in release builds?
- How do I prevent Xcode from including it?
2
Answers
after investigation, it seems to be an issue with
xcodebuild's caching. I have a script that analyzes, builds, bundles, and uploads the app to our content server. At the start of the script it would run the static analyzer:xcodebuild analyze -project "$SCRIPT_DIR/Redacted.xcodeproj" -destination generic/platform=macOS -scheme Redacted -configuration Release CONFIGURATION_BUILD_DIR="$BUILD_DIRECTORY" ...etc...later it would build the project:
xcodebuild -project "$SCRIPT_DIR/REDACTED.xcodeproj" -target REDACTED -target REDACTED -target REDACTED -parallelizeTargets -destination generic/platform=macOS -configuration Release CONFIGURATION_BUILD_DIR="$BUILD_DIRECTORY" build ...etc...the second xcodebuild was reusing artifacts created by the first xcodebuild, which caused the address sanitizer dylib to be included in the release build of the app.
To fix it, I made the script delete the $BUILD_DIRECTORY after the static analysis.
You’re right, you should not ship your app with runtime sanitizers enabled, they cost unnecessary performance and are often only targeting a small range of supported macOS versions.
But as far as I know, they’re not included if you do the preferred release process of creating an archive (
Product > Archive). I’m not aware of enabling them other than the schemes, and here they shouldn’t affect your archive builds. So in case you’re currently just building in Xcode and try to ship the resulting app, that’s not what you should ship.