Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Texture + Xcode 9.3/Swift 4.1 via Carthage is broken #873

Open
rainypixels opened this issue Apr 6, 2018 · 16 comments
Open

Texture + Xcode 9.3/Swift 4.1 via Carthage is broken #873

rainypixels opened this issue Apr 6, 2018 · 16 comments

Comments

@rainypixels
Copy link
Contributor

I downloaded Xcode 9.3 last night, ran carthage update (pointed at Texture's release branch), and rebuilt my project. It builds successfully, but SIGABRTs on run. I've done all the usual stuff: deleted derived data, removed texture and dependencies entirely from checkout/build folders (and done a fresh install), etc. but nothing has worked. I've also tried the master branch which bails during carthage update as follows:

🚀  carthage update --platform iOS

*** Fetching texture
*** Fetching PINOperation
*** Checking out PINRemoteImage at "3.0.0-beta.13"
*** Checking out PINOperation at "1.1.1"
*** Checking out libwebp at "v0.6.0"
*** Checking out PINCache at "3.0.1-beta.6"
*** Checking out texture at "2a0c6f8a420da91617202aa7bca67314ef8c97e4"
*** xcodebuild output can be found in /var/folders/b1/5l9q543x2mx8bb3zmfhl34m80000gn/T/carthage-xcodebuild.dtfS3T.log
*** Downloading PINCache.framework binary at "3.0.1-beta.6"
*** Downloading PINRemoteImage.framework binary at "3.0 beta 13: Animated WebP support / better GIF handling"
*** Downloading PINOperation.framework binary at "Just fixing some warnings"
*** Skipped building libwebp due to the error:
Dependency "libwebp" has no shared framework schemes for any of the platforms: iOS
*** Building scheme "AsyncDisplayKit" in AsyncDisplayKit.xcworkspace
Build Failed
	Task failed with exit code 65:
	/usr/bin/xcrun xcodebuild -workspace /Users/n/Documents/Digest/ios-app/app/Carthage/Checkouts/texture/AsyncDisplayKit.xcworkspace -scheme AsyncDisplayKit -configuration Release -derivedDataPath /Users/n/Library/Caches/org.carthage.CarthageKit/DerivedData/9.3_9E145/texture/2a0c6f8a420da91617202aa7bca67314ef8c97e4 -sdk iphonesimulator -destination platform=iOS\ Simulator,id=CC29BD18-EA09-4F9E-8822-56FABBB2B389 -destination-timeout 3 ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES build (launched in /Users/n/Documents/Digest/ios-app/app/Carthage/Checkouts/texture)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/b1/5l9q543x2mx8bb3zmfhl34m80000gn/T/carthage-xcodebuild.dtfS3T.log

Here's a sample project that reproduces the runtime error for the release branch. Be sure to run carthage update first; I deleted the Carthage folder to reduce the file size of the sample project:

SadTexture.zip

@benvigier
Copy link

+1

@iceMusic
Copy link

I have the same problem

*** Building scheme "AsyncDisplayKit" in AsyncDisplayKit.xcworkspace
Build Failed
Task failed with exit code 65:
/usr/bin/xcrun xcodebuild -workspace /trunk/Carthage/Checkouts/texture/AsyncDisplayKit.xcworkspace -scheme AsyncDisplayKit -configuration Release -derivedDataPath /Users/name/Library/Caches/org.carthage.CarthageKit/DerivedData/9.3_9E145/texture/2.3.1 -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/xh/0p311s3j6rl5nmm29_brfc340000gn/T/texture SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in trunk/Carthage/Checkouts/texture)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/xh/0p311s3j6rl5nmm29_brfc340000gn/T/carthage-xcodebuild.FbOUKy.log

@iceMusic
Copy link

in ASDefaultPlaybackButton.m

ASDefaultPlaybackButtonType buttonType = (ASDefaultPlaybackButtonType)[parameters[@"buttonType"] intValue];
UIColor *color = parameters[@"color"];

The two lines of code are wrong.
Expected method to read dictionary element not found on object of type 'id'

@CuredByLaughter
Copy link

seems this is related to #875

@iceMusic
Copy link

Refer to other partners' temporary solutions, declare parameters as NSDictionary
build ok
And then execute the command
carthage build --platform ios

  • (void)drawRect:(CGRect)bounds withParameters:(NSDictionary*)parameters isCancelled:(asdisplaynode_iscancelled_block_t)isCancelledBlock isRasterizing:(BOOL)isRasterizing

@rainypixels
Copy link
Contributor Author

rainypixels commented Apr 18, 2018

Looks like this may have been fixed and merged into master 6 days ago by @maicki. If anyone on this thread can confirm, I can go ahead and close this issue...

@jasonlagaac
Copy link

jasonlagaac commented Apr 26, 2018

I'm still having issues when using carthage:

The following build commands failed:
        CompileC /Users/jasonlagaac/Library/Caches/org.carthage.CarthageKit/DerivedData/9.3_9E145/texture/e67b892243ed715f3f8f72d13292446a97c520c1/Build/Intermediates.noindex/AsyncDisplayKit.build/Release-iphonesimulator/AsyncDisplayKit.build/Objects-normal/i386/ASAssert.o Source/Base/ASAssert.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler

I am using the master branch

@Saik0s
Copy link

Saik0s commented May 1, 2018

Hi! Here is a description of this error:
error: thread-local storage is not supported for the current target static _Thread_local int tls_mainThreadAssertionsDisabledCount; ^ 1 error generated.

This problem is only occurs when building for iphonesimulator with architecture i386.
For x86_64 build is successful.

@Adlai-Holler
Copy link
Member

Yes unfortunately Xcode 9.3 removed support for i386 (32-bit simulator) thread-local variables.

Since that particular architecture is pretty useless these days and will soon be phased out when we drop iOS 9 (not that we have concrete plans to do that,) I'd rather address why Carthage insists on building that architecture rather than fork all the places in our code where we rely on thread-local storage.

Not knowing much about Carthage, is there any way to configure what architectures are eagerly built? It seems like 64-bit simulator and ARM64 are the most relevant, and then 32-bit ARM in rare cases/App Store builds.

@Saik0s
Copy link

Saik0s commented May 2, 2018

Here is an easy workaround:
create a shell script with such content

#!/usr/bin/env bash

set -euo pipefail
IFS=$'\n\t'

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT
echo "ONLY_ACTIVE_ARCH[sdk=iphonesimulator*] = YES" >>$xcconfig
export XCODE_XCCONFIG_FILE="$xcconfig"

carthage update --platform ios $@

And use it to perform carthage update. This script will force carthage to build only active arch when building for iphonesimulator.

@ishall1
Copy link

ishall1 commented May 4, 2018

anyone can fix it?

@Saik0s
Copy link

Saik0s commented May 5, 2018

@ishall1 Why don't you just use my solution?

@bajtyngier
Copy link

bajtyngier commented May 5, 2018

I managed to fix my thread-local storage issue by setting the ONLY_ACTIVE_ARCH setting to true for any debugging targets (the problem seems to affect only builds against the simulator). I am using Cocoapods and fixed it by adding this little snippet to my Podfile:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        if target.name == 'Texture' then
            target.build_configurations.each do |configuration|
                if configuration.name.include?("Debug") then
                    configuration.build_settings['ONLY_ACTIVE_ARCH'] = 'YES'
                end
            end
        end
    end
end

@rainypixels
Copy link
Contributor Author

@Adlai-Holler Thanks for the hint! I'll look into whether there's a way to configure what architectures are built, or whether we would have to use a script. That said, quick heads up that this seems like an issue that's hitting cocoapods folk, too (see @bajtyngier's comment above).

@ishall1
Copy link

ishall1 commented May 6, 2018

@Saik0s Thanks for your reply. But your solution doesn't fix my problem . Now I use 'pod install' and it works well.

@mariancerny
Copy link

You could also be able to fix this if you remove i386 from VALID_ARCHS.
See Carthage/Carthage#1771 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests