Fix possible build errors from ENABLE_THREAD_SANITIZER=YES

[sinoru]

<unknown>:0: error: unsupported option '-sanitize=thread' for target 'arm64-apple-ios8.0'
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1

This can be happened when ENABLE_THREAD_SANITIZER=YES passed from Environment Variable. (e.g carthage build triggered in Thread Sanitizer enabled projects)

Because Thread Sanitizer only support in macOS and other device's simulators. If that parameter passes to iPhoneOS, watchOS, AppleTVOS build, it leads to build error.

This fix will prevent for that.

[mdiep]

Thanks for the PR!

[jdhealy]

Thanks for the PR — we should definitely make it easier of users of Carthage to configure the thread sanitizer.

In terms of build settings only applicable to certain platforms, XCDBLD ideally shouldn’t have intelligence of that, and Carthage/CarthageKit (while the better place for such logic) shouldn’t hardcode settings which might have applicability change between Clang/LLVM/Swift versions.

There is another way for a user to configure this behavior with the current version of Carthage, though very unintuitive.

tee ~/Library/Preferences/thread-sanitizer.xcconfig <<-'EOF'
ENABLE_THREAD_SANITIZER[sdk=macosx*] = YES
ENABLE_THREAD_SANITIZER[sdk=iphonesimulator*][arch=x86_64] = YES
ENABLE_THREAD_SANITIZER[sdk=appletvsimulator*][arch=x86_64] = YES
ENABLE_THREAD_SANITIZER[sdk=watchsimulator*][arch=x86_64] = YES
EOF

XCODE_XCCONFIG_FILE="${HOME}/Library/Preferences/thread-sanitizer.xcconfig" carthage build --no-skip-current

For unspecified SDKs and architectures in the xcconfig the default for ENABLE_THREAD_SANITIZER is applied.

How to inform a user of this solution:

We could, for a user who has set ENABLE_THREAD_SANITIZER as environment variable and received an error: unsupported option '-sanitize=thread' or similar, append a message in Carthage’s output advising on the unintuitive configuration, including a URL to a page with instructions.

Think I've figured out what’s necessary for Carthage to parse this error¹ and would appreciate your input (thanks again, @sinoru) once it’s posted².

1: plumbing changes necessary because the error: is on stdout not stderr 😤
2: just want to benchmark the stdout parsing to make sure it’s lightweight enough.

[jdhealy]

just want to benchmark the stdout parsing to make sure it’s lightweight enough

Mostly non-scientific¹, but seemingly no slower behavior with the parsing than without it.

Here’s a link to the work-in-progress of the stdout parsing.

TODO

• Investigate whether xcodebuild localizes the error.
• Write the user-facing messaging and codify in CarthageError.
• Create a page with instructions.
• Feedback, welcome at any time 👍

1: Non-scientific meaning: run on cloud CI, probably on a shared machine. Small, but not singular sample size.

[sinoru]

Actually, ENABLE_THREAD_SANITIZER is not in Xcode settings. It is inserted by Scheme setting.

Because of that, Can not be added platform specific settings. (e.g. ENABLE_THREAD_SANITIZER[sdk=iphonesimulator*][arch=x86_64])
Just Xcode ignore these settings, and add it as them ways forcibly.

[ikesyo]

I think -enableThreadSanitizer NO should be used which is documented in man xcodebuild instead.

[sinoru]

@ikesyo Ooops.. Yeah.. I should use that parameter.

[jdhealy]

Via someone I asked, their initial thought was that XCODE_XCCONFIG_FILE behavior should be okay¹ — waiting for an official response on the Apple Developer Forums.

You’re correct in the aspect: ENABLE_THREAD_SANITIZER is not listed on Apple’s build reference settings page.

But, xcodebuild² is definitely effected by an XCODE_XCCONFIG_FILE with ENABLE_THREAD_SANITIZER as evidenced by this Swift-less Objective-C project build output.

And alternatively, a xcscheme-enabled Thread Sanitized Swift-less Objective-C project can have it disabled via XCODE_XCCONFIG_FILE:

$ cat >! ~/Library/Preferences/platform-specific-thread-sanitizer.xcconfig <<-'EOF'
ENABLE_THREAD_SANITIZER[sdk=appletvsimulator*][arch=x86_64] = NO
EOF

$ grep 'enableThreadSanitizer' OMGHTTPURLRQ.xcodeproj/xcshareddata/xcschemes/OMGHTTPURLRQ.xcscheme
enableThreadSanitizer = "YES"
$ XCODE_XCCONFIG_FILE="${HOME}/Library/Preferences/platform-specific-thread-sanitizer.xcconfig" carthage build --no-skip-current --verbose --platform tvOS | grep 'fsanitize' || echo 'no «fsanitize» found'
no «fsanitize» found

Sidenote and caveat, still unclear whether the following behavior is a bug:

Works as expected on a clean `build`, but when there’s DerivedData, no `-fsanitize=thread` behavior is observed.

Also, the behavior is as-of-yet untested by me on Xcode 9’s XCBuild.

1: Okay in the general sense, considering I only posed the question in a generic way.
2: Xcode 8.3.3 · Build version8E3004b

[sinoru]

I'm sure that there are no localization for xcodebuild (Actually, that messages from swift compiler. And I can't find in swift repo.

I agree for that messages. But I don't think that we should refers to set that options by user. Carthage invoke the build iphoneos, iphonesimulator both, while Xcode only builds for one platform (which determines ENABLE_THREAD_SANITIZER=YES should be added for there own build process).

I means,
If user select parent project destination to Real Devices, Xcode will 'not' add ENABLE_THREAD_SANITIZER=YES, So Carthage will build iphonesimulator, iphoneos as ENABLE_THREAD_SANITIZER=NO.
If user select parent project destination to Simulator Devices, Xcode will add ENABLE_THREAD_SANITIZER=YES, So Carthage will build iphonesimulator, iphoneos as ENABLE_THREAD_SANITIZER=YES. Ant that is not supported in iphoneos.
So to avoid this issues, User should passes

ENABLE_THREAD_SANITIZER[sdk=iphoneos*] = NO
ENABLE_THREAD_SANITIZER[sdk=appletvos*] = NO
ENABLE_THREAD_SANITIZER[sdk=watchos*] = NO

for override Xcode's own settings.
(Because those build settings are available in Scheme, not Xcode Proj.)

It looks like kinda tricky way..

Well.. I might thinks wrong.
So feedbacks are welcome :)
How do you guys think about that?

[jdhealy]

@sinoru Thanks for your feedback!

I am not quite sure what you mean by “parent project” — is this parent/child relationship in terms of dependencies (meaning module imports)? Or something else?

[tmspzz]

ping

[sinoru]

Oh, sorry. I missed that.

@jdhealy I meant which project run the Carthage command by Build Script Phase.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.