Rxswift: Build error 65 with Xcode 10.2 (Swift 5)

[courteouselk]

Short description of the issue:

RxSwift 4.4.2 fails to build with:

• Xcode 10.2 (10E125)
• Carthage 0.32.0
• iOS platform

Expected outcome:

RxSwift builds.

What actually happens:

carthage update RxSwift --platform iOS --no-use-binaries

_Console output_:

*** Fetching RxSwift
*** Checking out RxSwift at "4.4.2"
*** xcodebuild output can be found in /var/folders/3s/n9cx3jx57ms9pcrn7yc14sl00000gn/T/carthage-xcodebuild.2K3DkT.log
*** Building scheme "RxAtomic" in Rx.xcworkspace
*** Building scheme "RxCocoa" in Rx.xcworkspace
Build Failed
    Task failed with exit code 65:
    /usr/bin/xcrun xcodebuild -workspace .../Carthage/Checkouts/RxSwift/Rx.xcworkspace -scheme RxCocoa -configuration Release -derivedDataPath .../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/3s/n9cx3jx57ms9pcrn7yc14sl00000gn/T/RxSwift SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in .../Carthage/Checkouts/RxSwift)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/3s/n9cx3jx57ms9pcrn7yc14sl00000gn/T/carthage-xcodebuild.2K3DkT.log

_Log file contents:_

...

Linting Swift files in current working directory
Linting 'Cancelable.swift' (1/283)
Could not cast value of type 'Swift.Int64' (0x1032abf80) to 'Swift.String' (0x1032b24d8).
.../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2/Build/Intermediates.noindex/ArchiveIntermediates/RxCocoa/IntermediateBuildFilesPath/Rx.build/Release-iphoneos/RxSwift.build/Script-A21F589121E109AD0051AEA2.sh: line 6: 72924 Abort trap: 6           swiftlint
Command PhaseScriptExecution failed with a nonzero exit code

Ditto .../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2/Build/Intermediates.noindex/ArchiveIntermediates/RxCocoa/IntermediateBuildFilesPath/Rx.build/Release-iphoneos/RxSwift.build/module.modulemap .../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2/Build/Intermediates.noindex/ArchiveIntermediates/RxCocoa/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/RxSwift.framework/Modules/module.modulemap (in target: RxSwift)
    cd .../Carthage/Checkouts/RxSwift
    builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -resolve-src-symlinks .../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2/Build/Intermediates.noindex/ArchiveIntermediates/RxCocoa/IntermediateBuildFilesPath/Rx.build/Release-iphoneos/RxSwift.build/module.modulemap .../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2/Build/Intermediates.noindex/ArchiveIntermediates/RxCocoa/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/RxSwift.framework/Modules

** ARCHIVE FAILED **


The following build commands failed:
        PhaseScriptExecution SwiftLint .../Library/Caches/org.carthage.CarthageKit/DerivedData/10.2_10E125/RxSwift/4.4.2/Build/Intermediates.noindex/ArchiveIntermediates/RxCocoa/IntermediateBuildFilesPath/Rx.build/Release-iphoneos/RxSwift.build/Script-A21F589121E109AD0051AEA2.sh
(1 failure)

Self contained code example that reproduces the issue:

// No Swift code needed.  Just try to build RxSwift after upgrading Xcode to 10.2

RxSwift/RxCocoa/RxBlocking/RxTest version/commit

4.4.2

Platform/Environment

• [x] iOS
• [ ] macOS
• [ ] tvOS
• [ ] watchOS
• [ ] playgrounds

How easy is to reproduce? (chances of successful reproduce after running the self contained code)

• [x] easy, 100% repro
• [ ] sometimes, 10%-100%
• [ ] hard, 2% - 10%
• [ ] extremely hard, %0 - 2%

Xcode version:

10.2 (10E125)

Installation method:

• [ ] CocoaPods
• [x] Carthage
• [ ] Git submodules

I have multiple versions of Xcode installed:

• [ ] yes (which ones)
• [x] no

Level of RxSwift knowledge:

• [ ] just starting
• [x] I have a small code base
• [ ] I have a significant code base

[kzaher]

Yeah, it was dumb of us to include swiftlint for all builds. This should have only been turned on for TRAVIS.

I'll make a new release this weekend.

[freak4pc]

Dumb might be a bit harsh :)

[kzaher]

I guess it’s more of a feeling, it should have been obvious to me that this would happen.

I was full of sugar around that time, so hoping that suggar was impairing my judgement.

[freak4pc]

The problem isn't the fact it runs on builds - the problems is it has rules that cause errors instead of warnings. If everything would be set to warnings, this wouldn't be an issue.

[kzaher]

@freak4pc I think it should be an error for CI. Otherwise what use do we have of it?

[freak4pc]

There is a specific flag for causing errors instead of warnings that can be used for CI.

[kzaher]

There is a specific flag for causing errors instead of warnings that can be used for CI.

But why should we depend on the behavior a program flag which can change at any time in the future? We can just not run it.

[freak4pc]

So people developing the project get linting warnings as they build, and not only on CI.

[kzaher]

I'm not sure that slight convenience is worth it. We have max 10 people at a particular time trying to contribute to the project and a lot more users.

Risking frustrating a lot of users, like we are doing with the latest build, for such small convenience isn't worth it IMHO. Even if this worked perfectly, any new contributor has ~0% chance of passing the CI at first try for any change, so I'm not sure this would matter much.

[freak4pc]

I think we'll disagree :) That interface didn't change for SwiftLint since it's first release.

The frustration of trying to contribute (as a newcomer) to a project and not knowing you are going against the project's style guide kinda sucks. If it can be avoided, I don't really see a reason why not to.

The risk you mention is really non-existent if you make everything warnings by default which is easy to do.

The only real issue here is that we didn't consider this being an issue for Carthage - if I would realize this earlier it would not have been an issue :)

Up to you, as usual, feel free to go with your instinct.

[kzaher]

I think we'll disagree :) That interface didn't change for SwiftLint since it's first release.

IMHO the only thing that matters is that it can change and break us. The fact that it hasn't doesn't mean much.

Even if we wanted to add swiftlint for everyone, I wouldn't rely of swiftlint to not change. I would rather depend on bash not changing swiftlint || true since we are already depending on it.

In any case, we screwed up. I'll make a new release this weekend. I'll add aLINT environment variable so in case anyone wants to run swiftlint locally they will be able to.

[tomschulz]

Thanks for your work guys. I am new to Carthage and have never used RXSwift, I just need it to build Moya. Right now I am choking on

/Users/tom/SportNinja/SaltTheEarth/Carthage/Checkouts/ReactiveSwift/Sources/Scheduler.swift:187:18: error: 'Hashable.hashValue' is deprecated as a protocol requirement; conform type 'DispatchSourceTimerWrapper' to 'Hashable' by implementing 'hash(into:)' instead
fileprivate var hashValue: Int {

[freak4pc]

So, two things:

1. I'm pretty sure you can build Moya without Rx (unless you're using RxMoya).
2. That hash(into:) thing should be a warning to the best of my memory, interesting that it's causing an error now, but I remember we fixed that specific issue and it seems unrelated to SwiftLint 🤔

[kzaher]

Hm, it doesn't look like this will be trivial. Xcode 10.2 has changed TSAN behavior again and it ignores our attempts to silence TSAN for atomic operations 😢

[freak4pc]

Fun times.

[kzaher]

I think I'm going to just use NSRecursiveLock for AtomicInt. It will be 10%-20% slower, although nobody will probably notice.

We can think about how to improve performance in 5.0. Don't think we can do anything else right now.

[freak4pc]

I think it's basically fine. We've tried our best to avoid this with RxAtomic in 4.4.x.

I guess the upside would be you can remove RxAtomic for the time being.

[kzaher]

I've changed the AtomicInt. 30cf72a533882ddf9f68d3f765a9f0a457bc7df2

I've tried to make it as light as possible to minimize the chances of rename accidents. This will probably be gone in 5.0 anyway.

Since this is more significant change then I've hoped, it would be great if people could smoke test the develop branch on their project before I release this and give me thumbs up is everything went ok.

And ofc, for some reason Xcode crashes and I can't make the release tests pass. Hopefully this will be released tomorrow.

[freak4pc]

Tagging people with significant code bases who might want to smoke test before 5.x: @alanzeino, @keith

[kzaher]

Interesting, integration tests for CocoaPods are failing on tvOS and iOS.

let scheduler = TestScheduler(initialClock: 0)

Test Case '-[CocoaPodsTvOSTests.TestRxCode testMap]' started.
failed to demangle superclass of TestScheduler from mangled name '7RxSwift20VirtualTimeSchedulerCy0A4Test0fecD9ConverterVG'
2019-04-01 21:26:05.728703+0200 CocoaPodsTvOS[99331:3661916] failed to demangle superclass of TestScheduler from mangled name '7RxSwift20VirtualTimeSchedulerCy0A4Test0fecD9ConverterVG'

[TimWatson]

develop branch builds and runs fine for me for iOS

[alanzeino]

Interesting, integration tests for CocoaPods are failing on tvOS and iOS. ...

@kzaher that looks like the -all_load issue in the 10.2 release notes

_{Sent with GitHawk}

[kzaher]

@alanzeino Where is that note? https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_release_notes

[kzaher]

Oh,

Linking against a static Swift library might create a binary with missing type metadata because the object files that define the metadata inside the static archive are mistakenly considered unused. (47598583)

This can manifest as a Swift runtime error with a message such as: “failed to demangle superclass of MyClass from mangled name ‘<mangled name>’”.

Workaround: If you can rebuild the static library, try building it with whole module optimization enabled. Otherwise, add -all_load to the linker flags in the client binary to ensure all object files are linked into it.

WTF, how the hell do they decide to release with these kinds of bugs. This is insane. In any case, this is on CocoaPods to solve IMHO.

[LucianoPAlmeida]

Hm, it doesn't look like this will be trivial. Xcode 10.2 has changed TSAN behavior again and it ignores our attempts to silence TSAN for atomic operations 😢

Hey @kzaher :))
I know is a little later to the discussion, but I was playing around with the TSan and RxAtomic branch and I think I've found an approach that seems like a solution for the issues still maintaining the RxAtomic.
But actually, you guys already removed the whole module so maybe is the goal to remove it already.
I posting this just in case you want to take a look to see and test if this is a valid approach to consider maintaining the RxAtomic. So maybe this could be useful :)
There is a PR here with some comments from a rxatomic-playaround to a branch in one commit after 4.5.0, in case you want to take a look on the diff or test it. Let me know if it does make sense :)

[freak4pc]

Hey, we actually already dropped RxAtomic in favor of AtomicInc (with RecursiveLock). I think kruno spent too much time chasing down TSAN oddities so it made sense to stop fiddling with it:)

[LucianoPAlmeida]

Yeah @freak4pc :))
I've noticed that, was just curious about the issue and want to drop this as an option to you guys maybe consider in a discussion moving forward 👍

Hey, we actually already dropped RxAtomic in favor of AtomicInc (with RecursiveLock). I think kruno spent too much time chasing down TSAN oddities so it made sense to stop fiddling with it:)

As you mention before: "Fun times" 😆

[freak4pc]

As always, appreciate your help 🙏🙏

[YiYiZheng]

Workaround: If you can rebuild the static library, try building it with whole module optimization enabled. Otherwise, add -all_load to the linker flags in the client binary to ensure all object files are linked into it.

The -all-load can't work. How to figure it out?
@kzaher

[freak4pc]

The all-load thing is Apple’s workaround since this is an Apple bug. If it doesn’t work for you? Im not sure there’s much to be done, it would work.

[c0diq]

Could you explain how one would set the LINT variable for Xcode to pick it up and run the swiflint build phase? My understanding is that Xcode does not inherit the shell environment variables when launched.
Or is this feature only for xcodebuild?

[freak4pc]

@c0diq what would be a reason to do this? This is internal linting for developing the lib and not for library consumers.

[c0diq]

So the main reason is that I am am trying to do the same for one of our library and the only way I have found is to source another bash file at the beginning of the build phase that would set that env variable.

The second reason, somewhat related, is that even if swiftlint doesn’t run, the build phase will still always execute because it has no input or output files, causing Xcode to think the library got rebuilt and have a cascading effect to other targets that link with it. In essence increasing build time even when nothing has changed.
For Xcode to not run the phase every time, it would need to detect changes to files that swiftlint would pick up but also observe an output file. The input is more complex and would require providing Xcode with a list of folders (it only does shallow monitoring) or a file list. The output could be a temporary file representing the output of swiftlint.

[trainvnexlesoft]

Interesting, integration tests for CocoaPods are failing on tvOS and iOS.

let scheduler = TestScheduler(initialClock: 0)

Test Case '-[CocoaPodsTvOSTests.TestRxCode testMap]' started.
failed to demangle superclass of TestScheduler from mangled name '7RxSwift20VirtualTimeSchedulerCy0A4Test0fecD9ConverterVG'
2019-04-01 21:26:05.728703+0200 CocoaPodsTvOS[99331:3661916] failed to demangle superclass of TestScheduler from mangled name '7RxSwift20VirtualTimeSchedulerCy0A4Test0fecD9ConverterVG'

Workaround: If you can rebuild the static library, try building it with whole module optimization enabled. Otherwise, add -all_load to the linker flags in the client binary to ensure all object files are linked into it.

The -all-load can't work. How to figure it out?

@kzaher

Any update about this? I'm facing with TestScheduler plz help

[freak4pc]

Still not an RxSwift bug ... this is on Apple's side as far as we can understand.

[nguyentrai2011]

Interesting, integration tests for CocoaPods are failing on tvOS and iOS.

let scheduler = TestScheduler(initialClock: 0)

Test Case '-[CocoaPodsTvOSTests.TestRxCode testMap]' started.
failed to demangle superclass of TestScheduler from mangled name '7RxSwift20VirtualTimeSchedulerCy0A4Test0fecD9ConverterVG'
2019-04-01 21:26:05.728703+0200 CocoaPodsTvOS[99331:3661916] failed to demangle superclass of TestScheduler from mangled name '7RxSwift20VirtualTimeSchedulerCy0A4Test0fecD9ConverterVG'

Workaround: If you can rebuild the static library, try building it with whole module optimization enabled. Otherwise, add -all_load to the linker flags in the client binary to ensure all object files are linked into it.

The -all-load can't work. How to figure it out?
@kzaher

Any update about this? I'm facing with TestScheduler plz help

Finally i found the solution in this case. I updated pod file structure
FROM:

target 'Demo' do
  use_frameworks!
  pod 'RxSwift'
  pod 'RxCocoa'
end
target 'DemoTests' do
    pod 'RxTest'
    pod 'RxBlocking'
end

TO

target 'Demo' do
  use_frameworks!
  pod 'RxSwift'
  pod 'RxCocoa'
  target 'DemoTests' do
    pod 'RxTest'
    pod 'RxBlocking'
  end
end

[clementprem]

Static libraries are now always force-loaded in their entirety during linking, fixing runtime errors related to demangling failures. (47598583)

Found this in Xcode 11 beta 7 release note