Carthage builds fail at xcrun lipo on Xcode 12 beta (3,4,5...)

Question

Carthage builds fail at xcrun lipo on Xcode 12 beta (3,4,5...)

sam-w opened this issue 4 years ago · 270 comments

carthage install method: [ ] .pkg, [x] homebrew, [x] source
which carthage: /usr/local/bin/carthage
carthage version: 0.35.0
xcodebuild -version: 12A8169g
Are you using --no-build? No
Are you using --no-use-binaries? No
Are you using --use-submodules? No
Are you using --cache-builds? No
Are you using --new-resolver? No

Cartfile

github "LoungeBuddy/Auth0.swift" "feature/decouple-keychain-manager"
binary "https://raw.githubusercontent.com/Instabug/Instabug-iOS/master/Instabug.json"

Carthage Output

> carthage build --platform iOS

*** xcodebuild output can be found in /var/folders/jm/pyy6p95j177_btm91tj0mkdm0000gn/T/carthage-xcodebuild.WPi9jL.log
*** Downloading binary-only framework Instabug at "https://raw.githubusercontent.com/Instabug/Instabug-iOS/master/Instabug.json"
*** Building scheme "JWTDecode-iOS" in JWTDecode.xcodeproj
Build Failed
	Task failed with exit code 1:
	/usr/bin/xcrun lipo -create /Users/swarn1/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/JWTDecode.swift/2.4.1/Build/Intermediates.noindex/ArchiveIntermediates/JWTDecode-iOS/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/JWTDecode.framework/JWTDecode /Users/swarn1/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/JWTDecode.swift/2.4.1/Build/Products/Release-iphonesimulator/JWTDecode.framework/JWTDecode -output /Volumes/Shared/LoungeBuddy/consumer-ios-app/Carthage/Build/iOS/JWTDecode.framework/JWTDecode

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/jm/pyy6p95j177_btm91tj0mkdm0000gn/T/carthage-xcodebuild.WPi9jL.log

Running the problem command:

> /usr/bin/xcrun lipo -create /Users/swarn1/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/JWTDecode.swift/2.4.1/Build/Intermediates.noindex/ArchiveIntermediates/JWTDecode-iOS/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/JWTDecode.framework/JWTDecode /Users/swarn1/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/JWTDecode.swift/2.4.1/Build/Products/Release-iphonesimulator/JWTDecode.framework/JWTDecode -output /Volumes/Shared/LoungeBuddy/consumer-ios-app/Carthage/Build/iOS/JWTDecode.framework/JWTDecode

fatal error: /Applications/Xcode-12-beta-3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: /Users/swarn1/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/JWTDecode.swift/2.4.1/Build/Intermediates.noindex/ArchiveIntermediates/JWTDecode-iOS/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/JWTDecode.framework/JWTDecode and /Users/swarn1/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/JWTDecode.swift/2.4.1/Build/Products/Release-iphonesimulator/JWTDecode.framework/JWTDecode have the same architectures (arm64) and can't be in the same fat output file

Actual outcome

Carthage fails to build any dependencies.
Carthage advises to look at a build log which ends with ** BUILD SUCCEEDED **

Expected outcome

Carthage should not fail to build.
On failures outside of xcodebuild, Carthage should not direct you to the build log.

Workaround
I guess the architecture for iphonesimulator has changed such that it now collides with iphoneos? Not sure how this stuff works. Either way, I've been able to work around the problem by changing Sources/CarthageKit/Xcode.swift:742 to argsForBuilding.onlyActiveArchitecture = true. Obviously, this is not a great solution.

Answer 1 · 2020-07-23T08:17:06.000Z

this is the problematic bit

the same architectures (arm64) and can't be in the same fat output file

There are two arm64 slices in both binaries. Not sure why this is, but it's not good news.

EDIT: Latest workaround version: #3019 (comment)

Answer 2 · 2020-07-23T09:35:31.000Z

Doesn't seem to be unique to my dependencies - I've tried it with a few others and have exactly the same problem Ildar Abdullin <notifications@github.com> wrote: “this is the problematic bit “the same architectures (arm64) and can't be in the same fat output file” There are two arm64 slices in both binaries. Not sure why this is, but it's not good news.” — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Answer 3 · 2020-07-23T11:08:23.000Z

Yes, I don't think it's unique to your case. Waiting for more feedback.

Answer 4 · 2020-07-23T12:13:21.000Z

I wonder if a temporary workaround could be to exclude the arm64 architecture for simulators in the project file settings or in a custom XCConfig? I'm fighting my own challenges with the latest Xcode beta so I can't verify myself immediately.

I think the long-term solution is to start using XCFrameworks instead of fat frameworks.

Answer 5 · 2020-07-23T12:18:20.000Z

I wonder if a temporary workaround could be to exclude the arm64 architecture for simulators in the project file settings or in a custom XCConfig

I think this could work.

If @sam-w is comfortable with the coding another approach, it would make sense to remove the arm64 slice with lipo from the simulator platform.

Answer 6 · 2020-07-23T23:45:49.000Z

Is there an approach based on a custom XCConfig that does work around this? I've tried putting the following into a .xcconfig file:

EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64

xcodebuild then fails with this error:

Build settings from command line:
    CARTHAGE = YES
    CLANG_ENABLE_CODE_COVERAGE = NO
    CODE_SIGN_IDENTITY = 
    CODE_SIGNING_REQUIRED = NO
    GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO
    ONLY_ACTIVE_ARCH = NO
    SDKROOT = iphoneos14.0
    SKIP_INSTALL = YES
    STRIP_INSTALLED_PRODUCT = NO

Build settings from configuration file '/.../xcode12.xcconfig':
    EXCLUDED_ARCHS = 

FIXME: Implement XCBuild support for macros in overriding parameters with condition sets:

	EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64

The only way I've seen to overcome that is to switch to the legacy build system.

Answer 7 · 2020-07-24T09:42:12.000Z

Even for temporary solution, i do not find Sources/CarthageKit/Xcode.swift file. and switching to legacy system, did not solve the problem to me.

Answer 8 · 2020-07-24T14:21:40.000Z

[possible workaround]

At this moment in time I can't try this myself but I've been suggested to try the following in a .xcconfig file

EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))

Can anyone try?

Answer 9 · 2020-07-24T14:55:50.000Z

@tmspzz this appears to work for me - no longer getting the duplicate architecture error mentioned above

Answer 10 · 2020-07-24T14:57:52.000Z

If possible someone with the Apple Silicon DTK should also try.

Answer 11 · 2020-07-24T18:28:08.000Z

[possible workaround]

At this moment in time I can't try this myself but I've been suggested to try the following in a .xcconfig file
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))
Can anyone try?

Very clever! I wish I'd thought of that.

If I understand what is going on correctly, I think this will make it so that the dependency will not work on Apple Silicon since the simulators there are running on arm64.

Answer 12 · 2020-07-25T00:17:54.000Z

Very clever! I wish I'd thought of that!

To be clear, not my original contribution. But the contributor is reading us 👀

Answer 13 · 2020-07-25T04:43:19.000Z

[possible workaround]

At this moment in time I can't try this myself but I've been suggested to try the following in a .xcconfig file
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))
Can anyone try?

In which xcconfig file that I should add this settings?

Answer 14 · 2020-07-27T03:27:16.000Z

I added a file calledtmp.xcconfig to the project and added the excludes:

EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))

Then I updated my update script file to export XCODE_XCCONFIG_FILE pointing to it like this:

# This export fixes an issues with the latest Xcode beta.
export XCODE_XCCONFIG_FILE=$PWD/tmp.xcconfig
carthage update --platform iOS --no-use-binaries --cache-builds

Answer 15 · 2020-07-27T11:27:33.000Z

Thank you @drekka for the detailed explanation of the workaround! I can confirm this works for Xcode 12 beta 3.

Answer 16 · 2020-07-28T14:36:43.000Z

Hi.
I using DTK and trying to install dependencies using suggested workaround.
I have created helper.xcconfig and .sh script with this

export XCODE_XCCONFIG_FILE=$PWD/helper.xcconfig
carthage update --platform iOS --no-use-binaries

but still getting this issue mentioned in the original post.

Maybe I misunderstanding something?

Answer 17 · 2020-07-28T15:07:23.000Z

@alekkania add --verbose to carthage, and double check at the top of the build log that your config is properly loaded.

Answer 18 · 2020-07-28T15:16:09.000Z

@alekkania if you are successful (and both simulator and device builds work), please confirm here.

Answer 19 · 2020-07-28T15:31:18.000Z

@bvirlet @tmspzz
`Build settings from command line:
CARTHAGE = YES
CLANG_ENABLE_CODE_COVERAGE = NO
CODE_SIGN_IDENTITY =
CODE_SIGNING_REQUIRED = NO
GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO
ONLY_ACTIVE_ARCH = YES
SDKROOT = iphoneos14.0
SKIP_INSTALL = YES
STRIP_INSTALLED_PRODUCT = NO

Build settings from configuration file '/Users/aleksander/Developer/iOS-app/helper.xcconfig':
EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)_NATIVE_ARCH_64_BIT$(NATIVE_ARCH_64_BIT))
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64 = arm64 arm64e armv7 armv7s armv6 armv8

note: Using new build system
note: Building targets in parallel
note: Using codesigning identity override:
note: Planning build
note: Constructing build description
warning: The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.4, but the range of supported deployment target versions is 9.0 to 14.0.99. (in target 'Charts' from project 'Charts')
`

seems ok but still getting the:
Build Failed Task failed with exit code 1: /usr/bin/xcrun lipo -create /Users/aleksander/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/Charts/v3.5.0/Build/Intermediates.noindex/ArchiveIntermediates/Charts/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Charts.framework/Charts /Users/aleksanderkania/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/Charts/v3.5.0/Build/Products/Release-iphonesimulator/Charts.framework/Charts -output /Users/aleksander/Developer/ios-app/Carthage/Build/iOS/Charts.framework/Charts

Answer 20 · 2020-07-28T15:32:36.000Z

@alekkania if you copy and past that last command, what do you see in the output?

/usr/bin/xcrun lipo -create /Users/aleksander/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/Charts/v3.5.0/Build/Intermediates.noindex/ArchiveIntermediates/Charts/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Charts.framework/Charts /Users/aleksanderkania/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/Charts/v3.5.0/Build/Products/Release-iphonesimulator/Charts.framework/Charts -output /Users/aleksander/Developer/ios-app/Carthage/Build/iOS/Charts.framework/Charts

Answer 21 · 2020-07-28T15:35:15.000Z

@bvirlet

fatal error: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: /Users/aleksander/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/Charts/v3.5.0/Build/Intermediates.noindex/ArchiveIntermediates/Charts/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Charts.framework/Charts and /Users/aleksander/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8169g/Charts/v3.5.0/Build/Products/Release-iphonesimulator/Charts.framework/Charts have the same architectures (arm64) and can't be in the same fat output file

one more thing. I have Carthage build with argsForBuilding.onlyActiveArchitecture = true
but without it still don't work

Answer 22 · 2020-07-28T16:18:49.000Z

Workaround that works with both Xcode 11 and 12

Works with all versions of Xcode 12 (except beta 1 and 2; but no-one should be using those anymore). Once XCFrameworks support lands in Carthage this workaround won’t be needed. However not that XCFrameworks puts some strict requirements on projects that most projects don’t comply with.

Note: This is a change from before where the script excluded arm64 for simulators by individual Xcode 12 version. It now removes it from all Xcode 12 based builds.

How to use

Save the script (👇) to your project (e.g. as a carthage.sh file).
Make the script executable chmod +x carthage.sh
Instead of calling carthage ... call ./carthage.sh ...
- E.g. ./carthage.sh build or ./carthage.sh update --use-submodules

Script

#!/usr/bin/env bash

# carthage.sh
# Usage example: ./carthage.sh build --platform iOS

set -euo pipefail

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT

# For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise
# the build will fail on lipo due to duplicate architectures.
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

export XCODE_XCCONFIG_FILE="$xcconfig"
carthage "$@"

Initial solution

To make the workaround work with both Xcode 11 and 12 I had to tweak the `EXCLUDED_ARCHS` statement a bit:

#!/usr/bin/env bash

# carthage-build.sh
# Usage example: ./carthage-build.sh --platform iOS

set -euo pipefail

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT

# For Xcode 12 (beta 3+) make sure EXCLUDED_ARCHS is set to arm architectures otherwise
# the build will fail on lipo due to duplicate architectures.
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

export XCODE_XCCONFIG_FILE="$xcconfig"
carthage build "$@"

A colleague of mine with a DTK is going to check how this impacts building and running. I’ll report back once we have the results.

Answer 23 · 2020-07-28T18:30:59.000Z

This workaroud with .xcconfig file works on Intel Mac 😳

Answer 24 · 2020-07-29T09:50:25.000Z

Perhaps a better solution is to support xcframework instead of using lipo...

Answer 25 · 2020-07-31T02:12:39.000Z

Found a work around to allow use with Xcode 12 beta 3. You need to build your Carthage with Xcode 12 beta 2 and then you can run it with Xcode 12 beta 3. No changing project settings or build settings. This worked for iOS and tvOS targets

Answer 26 · 2020-08-04T08:29:01.000Z

As mentioned the xcconfig fix doesn't seem to work for all frameworks, e.g. Lottie

The error message is

Undefined symbols for architecture armv7:
  "type metadata for Swift._StringObject.Variant", referenced from:
  outlined init with take of Swift._StringObject.Variant in AnimationKeypathExtension.o
  ld: symbol(s) not found for architecture armv7

Answer 27 · 2020-08-04T08:44:20.000Z

As mentioned the xcconfig fix doesn't seem to work for all frameworks, e.g. Lottie

The error message is

Undefined symbols for architecture armv7:
  "type metadata for Swift._StringObject.Variant", referenced from:
  outlined init with take of Swift._StringObject.Variant in AnimationKeypathExtension.o
  ld: symbol(s) not found for architecture armv7

That is something different and not related to lipo. See airbnb/lottie-ios#1228 for details. tl;dr update lottie-ios to the latest master and it should work with Xcode 12.

Answer 28 · 2020-08-05T02:14:00.000Z

For Xcode 12 beta 4, note that you will need to update the Xcode build number in the workaround script for Xcode 12 beta 3 from 12A8169g to 12A8179i.

Answer 29 · 2020-08-05T04:29:22.000Z

Xcode 12 beta 4 still build failed

carthage install method: [ ] .pkg, [v] homebrew, [] source
which carthage: /usr/local/bin/carthage
carthage version: 0.35.0
xcodebuild -version: 12A8179i
Are you using --no-build? No
Are you using --no-use-binaries? Yes
Are you using --use-submodules? No
Are you using --cache-builds? Yes
Are you using --new-resolver? No

carthage command line:

carthage update --platform iOS --cache-builds --no-use-binaries

Carthage Output:

Build Failed
	Task failed with exit code 1:
	/usr/bin/xcrun lipo -create /Users/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8179i/Alamofire/5.2.2/Build/Intermediates.noindex/ArchiveIntermediates/Alamofire\ iOS/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Alamofire.framework/Alamofire /Users/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8179i/Alamofire/5.2.2/Build/Products/Release-iphonesimulator/Alamofire.framework/Alamofire -output /Users/pathToProject/Carthage/Build/iOS/Alamofire.framework/Alamofire

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/yy/kl6ykdxn4yjdslm_sx_s2z3r0000gn/T/carthage-xcodebuild.7L5328.log

carthage-xcodebuild.7L5328.log :

Signing Identity:     "-"

    /usr/bin/codesign --force --sign - --timestamp\=none /Users/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A8179i/Alamofire/5.2.2/Build/Products/Release-iphonesimulator/Alamofire.framework

** BUILD SUCCEEDED **

Answer 30 · 2020-08-10T21:01:58.000Z

👋
I've successfully used @tmspzz's workaround script 😄

EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))```

I was wondering if someone could explain the impact of this though?
Am I correct in thinking that I've excluded an arm64 slice that would be my binary will not work on Apple Silicon?

Thanks!

Answer 31 · 2020-08-11T23:02:47.000Z

This issue exists with Xcode 12 Beta 4 as well.

Answer 32 · 2020-08-13T04:08:27.000Z

Anyone confirmed the workaround works well with beta4?

I'm working with #3019 (comment) way but I have been facing the same error.

Answer 33 · 2020-08-13T04:11:34.000Z

@hiragram The script from #3019 (comment) works with my update from #3019 (comment)

Answer 34 · 2020-08-13T04:32:07.000Z

@wooster Thank you. I've missed #3019 (comment) . But
Xcode version does not matter in #3019 (comment) I think.

Answer 35 · 2020-08-14T16:44:08.000Z

Anyone confirmed the workaround works well with beta4?

Yes works for Xcode 12 beta 4. Make sure you change the build number as indicated by @wooster. It does matter in the alternate variant of the script since you have "...BUILD_12A8169g". So should be :

echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8179i = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig

Answer 36 · 2020-08-17T22:17:47.000Z

none of the above worked for me; what I did - removed the arm64 arch from simulator build before creating the fat lib:

if [ "$XCODE_VERSION_MAJOR" -ge 1200 ]; then
    lipo -remove arm64 "${CURRENTCONFIG_SIMULATOR_DIR}/${EXECUTABLE_NAME}" -o "${CURRENTCONFIG_SIMULATOR_DIR}/${EXECUTABLE_NAME}"
fi

Answer 37 · 2020-08-18T15:54:42.000Z

Is there a workaround for Cocoapods as well? Or any new version that supports Xcode 12 beta 4??
Cheers

Answer 38 · 2020-08-18T19:31:11.000Z

This is still an issue in Xcode 12 Beta 5

Answer 39 · 2020-08-19T06:40:14.000Z

The key is iPhoneSimulator on AppleSilicon is arch arm64 and iPhoneSimulator conflict with iPhoneOS library on the same arch arm64. So far , if remove arm64 from iPhoneSimulator works well. But after AppleSilicon migration finished, we also face this issue, maybe apple will update fat library format with compatible

Answer 40 · 2020-08-19T15:13:39.000Z

@dehengxulipo can not do that (You can not bundle the same architecture twice in one binary.), they use XCFramworks for that situation, where the folder structure contains 2 binaries where there is not duplicated architecture in each the binary. My guess is that Carthage will need XCFramwork for Xcode 12 (or make certain to remove one of the conflicting arm64 slices before using lipo?, are the arm64 slices equivalent?, no idea?). But this is just a guess.

Answer 41 · 2020-08-20T16:09:59.000Z

Does anyone know if there's officially a line of work to address this?

Answer 42 · 2020-08-21T12:57:37.000Z

A propper solution would be to make XcFrameworks work -> #2801
This hack has implication on SwitUI -> you cannot use SwiftUI previews if you rely on a framework built with this hack beacause it needs the arm64 simulator slice, wich is removed by the present hack

Answer 43 · 2020-08-22T19:59:33.000Z

After 40+ hours spent on XCFramworks and Carthage, I do not think they are the short-term solution for Carthage. Here is what I learned and a solution I implemented! (This is an update to #3019 (comment)).

Working with XCFramworks (with BUILD_LIBRARY_FOR_DISTRIBUTION=true) will introduce some limitations due to forward compatibility needed for different tool chains (swift/xcode versions)! I learned the following by trying to build XCFrameworks for a resolved Carthage dependency graph and creating multiple small demo projects to reproduce issues!

Be careful, if you build a module A (example PINOperation) that depends on a module B (example PINCache). By creating the XCFramwork of B some symbols may be striped out (for optimization). The framework A is usually built by linking to a checkout copy of the source code of B. This means A may assume the presence of some symbols in B (since it sees the source code) that will not be there in the XCFramework B! When you link the XCFramwork A and B to your app, at runtime you will get an error like: dyld: lazy symbol binding failed: Symbol not found: _$symbol_nameCvau Referenced from:A Expected in: B
Issues with minimum deployment version for targets: By creating an XCFramwork with a low minimum version (let us say iOS 10) and adding it to a project of a recent minimum version, let us say iOS 13.4, I saw an issue where the compiler was looking for a symbol like swift::swift50override_conformsToProtocol in the swift runtime library, but it was not included by the app targeting 13.4 (this symbol may be removed for optimization!)
Fun fact for XCFrameworks: you can not override functions marked @objc in extensions for apps targeting lower than iOS 13. (Not too bad, just move the code in the base class!)
SwiftUI previews #3019 (comment).
Xcode 12 note: the VALID_ARCHS setting is not supported in Xcode 12 beta 5, some project may not be compiling if they have a hardcoded a list of architectures! No devices or simulators will show in the Xcode list of devices to target for a build until you remove this setting or add the missing architectures!

Solution.

I created a custom version of Carthage (clone it and compile it) that used lipo to see if there was an arm64 slice for the device and the simulator binary. If it was the case, I used lipo to remove the arm64 slice from the simulator binary before merging the simulator and device binaries (with lipo). This could be a problem, because the arm64 slices could be different and it would break on apple silicon for simulator build! Also this does not respact the Xcode configurations define by the user, That would need to be validated!

Here are the tools that really helped me during this exploration.

lipo: To see, add remove architectures from a binary.
nm to see symbols in a binary
otool to see linked dynamic frameworks in a binary.

[Update] Long term it would be nice to support XCFrameworks! Because you compile them once, and they work with future version of the compiler! You can distribute the binaries for multiple version of Xcode, until you update your dependencies! In my case, after a lot of work, I was able to get XCFrameworks working by building them in Xcode 11.6 after fixing all of the errors mentioned above (a lot of updates to source code). Basically cloning each repo of the resolved graph of dependencies, building the XCFrameworks of the child nodes dependencies and linking them against intermediate dependencies to build their XCFrameworks, until going to the top of the dependency graph. The final result worked for both Xcode 12 and 11! But again, a lot of compile / runtime crashes to fix! But this is definitely not a good solution, just a fun experiment!

Answer 44 · 2020-08-23T07:23:49.000Z

Here is the real solution: Swift Package Manager.

Carthage is a poorly-maintained project where the "maintainers" ignore and don't merge approved PRs, leaving users high and dry.

Don't waste further time on Carthage.

Answer 45 · 2020-08-23T08:29:03.000Z

@1oo7 Jonathan believe me, I feel your frustrations but I do not think your comment was either kind or necessary. People work hard on this project, using their own free time to produce something you don't have to pay for. This is a complex problem and there are many things the maintainers have to consider when making changes. I agree that sometimes the comms with Carthage users could be better, but again: these are people spending their own free time to produce something you don't have to pay for. I think an apology and retraction is in order.

(also, SPM has its own problems and is not possible to use in plenty of situations, so it's not the coverall solution you're making it out to be)

Answer 46 · 2020-08-23T17:33:44.000Z

I added a file calledtmp.xcconfig to the project and added the excludes:

EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))

Then I updated my update script file to export XCODE_XCCONFIG_FILE pointing to it like this:

# This export fixes an issues with the latest Xcode beta.
export XCODE_XCCONFIG_FILE=$PWD/tmp.xcconfig
carthage update --platform iOS --no-use-binaries --cache-builds

Thank you @drekka
It works for Xcode 12.0 beta 3

Answer 47 · 2020-08-23T21:25:25.000Z

I agree that sometimes the comms with Carthage users could be better, but again: these are people spending their own free time to produce something you don't have to pay for. I think an apology and retraction is in order.

My comment is not directed at all the people making efforts to improve Carthage, it's directed at the people with authority to merge PRs who don't bother to do so for months on end.

I went to a lot of trouble to make this PR to Carthage earlier this year, well before COVID, to fix a critical production issue we had. That PR got approved, then summarily ignored by maintainers until it was closed from being "stale", after which there were other people also asking for it.

I would love it if the maintainers actually refused PRs on reasonable grounds that they communicated on PR comments, or accepted PRs if they had no objections... but they don't.

Since then there have been six other approved PRs also closed for being stale. Who deserves an apology, are the authors of all those PRs.

Because the net result is that using Carthage is a liability for anyone where being on the latest Xcode matters, because even if you make a PR to fix an issue to unblock use of the latest Xcode then it is very unlikely that the maintainers will actually merge that PR or even comment why they won't merge it.

these are people spending their own free time

I don't think they are "spending their own free time" though. If the folks with authority to merge PRs were actually spending any time on Carthage then approved PRs would not be more likely to expire than to get merged.

I'm sorry, but I'm just stating the apparent reality of the situation, hopefully to save others from what I went through. Hopefully that is no longer the case, and if so then I would be happy to take back what I said.

Answer 48 · 2020-08-24T09:08:44.000Z

I thank the anonymous benefactor for one of the most contrived and excellent work-arounds I've seen. I already had a custom xcconfig in place for Carthage and added the two lines mentioned above for excluding arm64 on the simulator. With these I can build a fairly large set of frameworks successfully on Xcode 12 beta 5. I'm good until I get my arm64 Mac.

EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))

Answer 49 · 2020-08-24T09:28:23.000Z

Thanks for your contribution, I used your 2 lines of code above but the error still stuck with me on Xcode 12 beta 5.

Answer 50 · 2020-08-24T13:30:02.000Z

I've noticed some new problems in Xcode 12 Beta 5 with this work around.

I can build for device and simulator, but when I try to run a SwiftUI Preview, I get the following error:

module 'Charts' was created for incompatible target arm64-apple-ios13.0

Not sure what the core issue is at the moment.

Answer 51 · 2020-08-24T18:14:54.000Z

I added a file calledtmp.xcconfig to the project and added the excludes:
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))
Then I updated my update script file to export XCODE_XCCONFIG_FILE pointing to it like this:
# This export fixes an issues with the latest Xcode beta.
export XCODE_XCCONFIG_FILE=$PWD/tmp.xcconfig
carthage update --platform iOS --no-use-binaries --cache-builds
Thank you @drekka
It works for Xcode 12.0 beta 3

Yes thanks so much on the workaround. This works for me on Xcode 12.0 beta 5. However, it cannot build for SwiftUI Preview. But at least my project can compile for now.

Answer 52 · 2020-08-25T03:50:05.000Z

@drekka Thanks for the bypass tip, works for Xcode 12 beta 4, 5

Answer 53 · 2020-08-25T07:16:55.000Z

I added a file calledtmp.xcconfig to the project and added the excludes:
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))
Then I updated my update script file to export XCODE_XCCONFIG_FILE pointing to it like this:
# This export fixes an issues with the latest Xcode beta.
export XCODE_XCCONFIG_FILE=$PWD/tmp.xcconfig
carthage update --platform iOS --no-use-binaries --cache-builds
Thank you @drekka
It works for Xcode 12.0 beta 3
Yes thanks so much on the workaround. This works for me on Xcode 12.0 beta 5. However, it cannot build for SwiftUI Preview. But at least my project can compile for now.

Some issue here. I can build for the simulator, but the SwiftUI preview does not work.

Answer 54 · 2020-08-25T08:10:37.000Z

Thank you @drekka
It works for Xcode 12.0 beta 5, I made some changes in the script file, yes and it works. Thank you!

sudo XCODE_XCCONFIG_FILE=$PWD/tmp.xcconfig carthage update --platform iOS

Answer 55 · 2020-08-25T12:40:38.000Z

Since we are nearing the release of iOS14:
If we have to go live using the workaround from this thread, are there any major drawbacks? I understand, that the slices needed for the simulator on Apple Silicon are missing, so it won't work on that architecture. But is there anything else to keep in mind? Could there be problems in the Apple review process?

Answer 56 · 2020-08-26T19:50:37.000Z

Workaround doesn't work for watchOS projects.
We had to include arm64 - modifying the workaround and adding arm64 seems to be working for us with having watchOS version of our application.

Answer 57 · 2020-08-27T09:09:09.000Z

@rastersize seems the script on Xcode beta 6 is broken. Please help update?

update:
I read the script and find the trick

works for Xcode beta 6


# carthage-build.sh
# Usage example: ./carthage-build.sh --platform iOS

set -euo pipefail

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT

# For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise
# the build will fail on lipo due to duplicate architectures.
# Xcode 12 Beta 3:
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8169g = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 4
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8179i = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 5
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8189h = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 6
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8189n = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig

echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$(XCODE_PRODUCT_BUILD_VERSION))' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

export XCODE_XCCONFIG_FILE="$xcconfig"
echo $XCODE_XCCONFIG_FILE
carthage update "$@"

Answer 58 · 2020-08-27T09:15:19.000Z

Here is the real solution: Swift Package Manager.

Carthage is a poorly-maintained project where the "maintainers" ignore and don't merge approved PRs, leaving users high and dry.

Don't waste further time on Carthage.

I can't believe. I use SPM and it just download the package to derivedData, which is stupid - if you clear it then you will have to repeat the process.

Carthage is smarter than this.

Answer 59 · 2020-08-27T10:12:00.000Z

Here is the real solution: Swift Package Manager.

Carthage is a poorly-maintained project where the "maintainers" ignore and don't merge approved PRs, leaving users high and dry.

Don't waste further time on Carthage.

I can't believe. I use SPM and it just download the package to derivedData, which is stupid - if you clear it then you will have to repeat the process.

Carthage is smarter than this.

Not that this is the appropriate forum for this conversation, but I highly disagree with this. The way that both Carthage and Cocoapods handles downloaded cache is borderline.. well poorly thought out. CI/CD is consistently an issue due to the global caching issues presented by these poor paradigms. SPM definitely has it closer to right from both a file path exclusion and separation perspective to handling cache collisions.

Answer 60 · 2020-08-28T10:01:20.000Z

For those who want SwifUI previews to work when linked to dependencies using this workaround, just also apply the same settings to the project including your preview

Answer 61 · 2020-08-28T17:13:37.000Z

@liuxuan30 Will confirm that your solution works for Xcode 12 beta 6. Thanks.

Answer 62 · 2020-08-28T19:52:52.000Z

Would it also be an option to simply disable the lipo-ing behavior of Carthage?

Answer 63 · 2020-08-28T21:56:34.000Z

@1oo7 with the way it works now you could not. This is because Carthage first build for simulator and after for device. If you do not merge the 2 binaries, you would be missing symbols for a certain architecture. For example, just building for the simulator and linking with the app and building for device would fail! When Xcode has the source code, it creates a folder for iphone and one for simulator in derived data, so this problem never happens by having 2 binaries! You could have 2 binary and maybe conditionally linking? But the way apple solved it was with XCframeworks, it has a similar folder structure with multiple binaries per device.

Answer 64 · 2020-09-09T02:00:17.000Z

This is because Carthage first build for simulator and after for device

Why?

Could we patch Carthage to just build all the architectures in one go? What is the point of building the simulator binaries separately from the device ones and then lipo-ing them together?

Answer 65 · 2020-09-10T21:49:18.000Z

Hi, I would like to try this out, but unsure about some details. Where would you save this file .... in your project (next to Cartfile), or in the Carthage directory? And we don't have to do anything else other than run this (someone mentioned a 'temp.xcconfig' file earlier in the thread)? Thanks for any feedback.

Answer 66 · 2020-09-10T21:55:32.000Z

Is there any plan on the part of the Carthage devs to address this issue in a more systematic way? iOS 14 goes live in less than a week, and while it's good there appears to be a workaround, disabling support for targeting Apple Silicon is obviously not a sustainable solution given where things are headed.

Answer 67 · 2020-09-10T22:02:43.000Z

Hi, I would like to try this out, but unsure about some details. Where would you save this file .... in your project (next to Cartfile), or in the Carthage directory? And we don't have to do anything else other than run this (someone mentioned a 'temp.xcconfig' file earlier in the thread)? Thanks for any feedback.

Save in a file with .sh extension carthage-build.sh
Make the file executable chmod +x ./carthage-build.sh
Run it instead of running Carthage directly ./carthage-build.sh --platform iOS

Answer 68 · 2020-09-14T09:20:23.000Z

@rastersize seems the script on Xcode beta 6 is broken. Please help update?

update:
I read the script and find the trick

works for Xcode beta 6


# carthage-build.sh
# Usage example: ./carthage-build.sh --platform iOS

set -euo pipefail

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT

# For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise
# the build will fail on lipo due to duplicate architectures.
# Xcode 12 Beta 3:
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8169g = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 4
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8179i = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 5
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8189h = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 6
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8189n = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig

echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$(XCODE_PRODUCT_BUILD_VERSION))' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

export XCODE_XCCONFIG_FILE="$xcconfig"
echo $XCODE_XCCONFIG_FILE
carthage update "$@"

what happen if I remove the line "carthage update "$@"", can I continue update carthage in terminal ?

Answer 69 · 2020-09-14T10:01:05.000Z

what happen if I remove the line "carthage update "$@"", can I continue update carthage in terminal ?

$@ simply adds any other command line params you add.
Personally I changed the line to carthage "$@" then I can run
./carthage-build.sh build --platform iOS
or
./carthage-build.sh update --platform iOS

Answer 70 · 2020-09-14T14:03:50.000Z

@dthientruc I think you copied the script from someone else’s comment. Yeah that last line carthage update "$@" should be carthage build "$@" to use it as a replacement for carthage build. Or you can change that line to be carthage "$@" and use it as @ddaddy showed.

Answer 71 · 2020-09-14T20:20:31.000Z

Posting this Carthage branch here, which has helped me get past this issue temporarily so I can start using Xcode 12 betas. I'm hoping the Xcode 12 GM will be fixed so I won't have to use this hacky fix anymore.

This is also an issue if you are using plain xcodebuild commands (xcodebuild archive then xcodebuild -create-xcframework fails for the same reasons). Hopefully the Xcode GM will not produce arm64 slices when archiving for device and simulators, which seems to be the root of the problem. This isn't actually a Carthage issue. I have since been able to create an xcframework using Xcode beta 6. The phoneos and iphonesimulator archives both contained arm64 and the -create-xcframework command was successful.

To use my (hacky) fix, download my fork, checkout that branch (feature/xcode-12-lipo-issue), then run make installables to create a modified version of Carthage that will exclude arm64 from simulator builds. Find the modified version of Carthage in the .build/release folder.

I could see this fix causing issues if you are running the final Carthage frameworks on an arm64 simulator, specifically with #if targetEnvironment(simulator) checks. I would expect it to think it's running on a device when its not.

☠️ Use at your own risk. Don't submit to the App Store with this. ☠️

Answer 72 · 2020-09-15T08:50:51.000Z

@marc-scig

Is there any plan on the part of the Carthage devs to address this issue in a more systematic way? iOS 14 goes live in less than a week, [...]

Were did you hear that? The Developer site still lists Beta 6 as the latest version, there's no GM yet...?

Answer 73 · 2020-09-15T11:26:25.000Z

@dthientruc I think you copied the script from someone else’s comment. Yeah that last line carthage update "$@" should be carthage build "$@" to use it as a replacement for carthage build. Or you can change that line to be carthage "$@" and use it as @ddaddy showed.

Thank for your answer, but when I build my ios app on Bitrise, i have to separate carthage config file and carthage-build.sh file because on bitise, carthage is built independent. Is there any solution to delete "carthage update "$@"" and still run carthage normally on terminal ? Or your answer is just only solution ?

Answer 74 · 2020-09-15T19:39:11.000Z

Xcode 12 GM is now live and iOS 14 launches in less than 24 hours. Any updates?

Answer 75 · 2020-09-15T19:47:02.000Z

Seems GM still contains this problem 😭

Answer 76 · 2020-09-15T20:15:56.000Z

Just to be clear, this is not an Xcode issue, Xcode is doing what it is supposed to do to support simulators for both arm64 and x_86 simulator builds (supporting the future arm_64 macs). The issue is that the binary created from the simulator archive and the device archive (by Carthage) now both have an arm64 slice (and it is supposed to be that way in the general situation)! So the strategy used by Carthage to bundle simulator and device binaries together will not work if trying to support the arm_64 for device and simulator builds at the same time. Also see, #3019 (comment). Also, this is why disabling arm_64 for simulator builds makes the issue go way! (not a long term solution!)

Answer 77 · 2020-09-15T20:39:59.000Z

The workaround updated for Xcode 12 GM:

# carthage-build.sh
# Usage example: ./carthage-build.sh --platform iOS

set -euo pipefail

xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX)
trap 'rm -f "$xcconfig"' INT TERM HUP EXIT

# For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise
# the build will fail on lipo due to duplicate architectures.
# Xcode 12 Beta 3:
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8169g = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 4
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8179i = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 5
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8189h = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 beta 6
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A8189n = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 GM
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A7208 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
# Xcode 12 GM (updated build)
echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A7209 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig

echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$(XCODE_PRODUCT_BUILD_VERSION))' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

export XCODE_XCCONFIG_FILE="$xcconfig"
echo $XCODE_XCCONFIG_FILE
carthage update "$@"

Answer 78 · 2020-09-15T22:53:11.000Z

@marc-scig

Is there any plan on the part of the Carthage devs to address this issue in a more systematic way? iOS 14 goes live in less than a week, [...]

Were did you hear that? The Developer site still lists Beta 6 as the latest version, there's no GM yet...?

GM releasing tomorrow 😀

Answer 79 · 2020-09-15T23:44:11.000Z

@Sn0w0d
Yes, I'm seeing it now (and donwloading all of its 11 GB). When I posted my comment, only Beta 6 was available...

Answer 80 · 2020-09-16T05:03:49.000Z

@hansemannn My build number for the Xcode GM was 12A7209 (9 instead of 8 for the final number. Looks like maybe a new GM was put out or I'm missing something...

Answer 81 · 2020-09-16T07:21:10.000Z

The script works for me but when I try to build app in release mode on simulator I get
Module 'Rswift' was created for incompatible target arm64-apple-ios8.0: /Users/**/App/Carthage/Build/iOS/Rswift.framework/Modules/Rswift.swiftmodule/arm64.swiftmodule

Is building in release working for others?

Answer 82 · 2020-09-16T08:14:04.000Z

This has not been fixed in Xcode 12 GM, is Carthage going to fix this issue?

Answer 83 · 2020-09-16T08:22:22.000Z

@bukira Please read #3019 (comment). Thanks

Answer 84 · 2020-09-16T08:24:13.000Z

that's a work around but not a fix, can apps be submitted using this? I use Sophie to do Carthage commands

Answer 85 · 2020-09-16T08:26:50.000Z

The workaround should have no impact on submission unless you plan to release for Apple silicon.

Answer 86 · 2020-09-16T08:29:36.000Z

but no cathage build with this in?

Answer 87 · 2020-09-16T08:48:09.000Z

but no cathage build with this in?

This workaround is not suitable for Carthage itself.

Answer 88 · 2020-09-16T08:49:12.000Z

is there a plan moving forward?

Answer 89 · 2020-09-16T08:51:47.000Z

xcframewoks #2881

Answer 90 · 2020-09-16T08:52:12.000Z

@tmspzz I'm also interesting to see if Carthage has a solution for this problem or we should start using other package managers. The issues I'm seeing even with this workaround is that the existing frameworks that I'm using don't really compile correctly (fbsdk, realm etc.) and I'm wondering if Carthage will be able to help with this or not.

Answer 91 · 2020-09-16T08:54:02.000Z

xcframewoks #2881

and what's that?

Answer 92 · 2020-09-16T08:54:11.000Z

@tmspzz I'm also interesting to see if Carthage has a solution for this problem or we should start using other package managers. The issues I'm seeing even with this workaround is that the existing frameworks that I'm using don't really compile correctly (fbsdk, realm etc.) and I'm wondering if Carthage will be able to help with this or not.

See my previous comment.

However I think that eventually the community should converge to swiftPM.

Answer 93 · 2020-09-16T08:56:27.000Z

so end of Carthage then? SwiftPM or cocoaPods moving forward? better to know now than waste time investing in Carthage, even thou I love Carthage over others

Answer 94 · 2020-09-16T09:01:33.000Z

What I don't like about spm or cocoapods is that we're wasting a lot of time fetching / compiling dependencies in case you clear the project. Last year when preparing my app for catalyst I ended up compiling my dependencies as xcframeworks "by hand" and probably that will be a solution for now.

Answer 95 · 2020-09-16T09:10:52.000Z

This workaround don't works with https://github.com/realm/realm-cocoa , help

Answer 96 · 2020-09-16T09:17:02.000Z

You can't even use XCFramework if you target iOS 12 or older. Using swift structs makes it crash when you build a framework with BUILD_LIBRARY_FOR_DISTRIBUTION = YES
https://bugs.swift.org/browse/SR-11969

Answer 97 · 2020-09-16T09:22:22.000Z

I think if this issue does not arise from Xcode 12 GM, so we need to wait for Carthage fix this issue, and if there isn't any solution, we have to remove Carthage out of iOS app and use cocoaPods instead.

Answer 98 · 2020-09-16T09:28:51.000Z

I think if this issue does not arise from Xcode 12 GM, so we need to wait for Carthage fix this issue, and if there isn't any solution, we have to remove Carthage out of iOS app and use cocoaPods instead.

which is a sad day as I hate cocopods, "Rome" for cocoapods is great thou as creates frameworks like Carthage and doesn't require cocopods in the project file, you can use them like you would Carthage frameworks

Answer 99 · 2020-09-16T09:57:10.000Z

The workaround script was not working for me on 12 GM, I had to replace
# Xcode 12 GM echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A7208 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
with
# Xcode 12 GM echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12A7209 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig

Now it's working.

Answer 100 · 2020-09-16T10:00:02.000Z

@tibo9 yes, but this workaround do not works for all packages....