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: https://github.com/Carthage/Carthage/issues/3019#issuecomment-693302447

tmspzz on 23 Jul 2020

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.

sam-w on 23 Jul 2020

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

tmspzz on 23 Jul 2020

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.

DavidBrunow on 23 Jul 2020

👍2

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.

tmspzz on 23 Jul 2020

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.

patrickhartling on 24 Jul 2020

👍1

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.

karapurakesh on 24 Jul 2020

[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?

tmspzz on 24 Jul 2020

😕5 👍5

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

sebskuse on 24 Jul 2020

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

tmspzz on 24 Jul 2020

[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.

DavidBrunow on 24 Jul 2020

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

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

tmspzz on 25 Jul 2020

[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?

khairilushan on 25 Jul 2020

👍6

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

drekka on 27 Jul 2020

❤108 👍46 🎉11 👀1

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

funkenstrahlen on 27 Jul 2020

👍7

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?

alekkania on 28 Jul 2020

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

bvirlet on 28 Jul 2020

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

tmspzz on 28 Jul 2020

@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

alekkania on 28 Jul 2020

@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

bvirlet on 28 Jul 2020

@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

alekkania on 28 Jul 2020

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.

rastersize on 28 Jul 2020

👍291 ❤109 🚀50 🎉16 👀4 👎2

This workaroud with .xcconfig file works on Intel Mac 😳

alekkania on 28 Jul 2020

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

quentinfasquel on 29 Jul 2020

👍9

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

BryanNorden on 31 Jul 2020

👍1

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

EmDee on 4 Aug 2020

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 https://github.com/airbnb/lottie-ios/issues/1228 for details. tl;dr update lottie-ios to the latest master and it should work with Xcode 12.

florianbuerger on 4 Aug 2020

👍1

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.

wooster on 5 Aug 2020

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 **

AlexanderPan on 5 Aug 2020

👍21 😕4

👋
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!

bboyle18 on 10 Aug 2020

👀3 👍2

This issue exists with Xcode 12 Beta 4 as well.

jaredsinclair on 12 Aug 2020

👍13

Anyone confirmed the workaround works well with beta4?

I'm working with https://github.com/Carthage/Carthage/issues/3019#issuecomment-664099506 way but I have been facing the same error.

hiragram on 13 Aug 2020

@hiragram The script from https://github.com/Carthage/Carthage/issues/3019#issuecomment-665136323 works with my update from https://github.com/Carthage/Carthage/issues/3019#issuecomment-668934262

wooster on 13 Aug 2020

@wooster Thank you. I've missed https://github.com/Carthage/Carthage/issues/3019#issuecomment-668934262 . But
Xcode version does not matter in https://github.com/Carthage/Carthage/issues/3019#issuecomment-664099506 I think.

hiragram on 13 Aug 2020

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

npvisual on 14 Aug 2020

👍2

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

2energycell on 18 Aug 2020

👍1

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

Raphzz on 18 Aug 2020

This is still an issue in Xcode 12 Beta 5

gbreen12 on 18 Aug 2020

😕28

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

dehengxu on 19 Aug 2020

@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.

Screen Shot 2020-08-19 at 10 45 44 AM

simonpierreroy on 19 Aug 2020

👍5 😄1

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

ThePragmaticArt on 20 Aug 2020

👀8

A propper solution would be to make XcFrameworks work -> https://github.com/Carthage/Carthage/pull/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

lilpit on 21 Aug 2020

👍5

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 https://github.com/Carthage/Carthage/issues/3019#issuecomment-676487951).

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 https://github.com/Carthage/Carthage/issues/3019#issuecomment-678276531.
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!

simonpierreroy on 22 Aug 2020

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.

1oo7 on 23 Aug 2020

👎22 👍3

@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)

sam-w on 23 Aug 2020

❤20

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

CocoaDebug on 23 Aug 2020

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.

1oo7 on 23 Aug 2020

👍2

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))

stevenkramer on 24 Aug 2020

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

tranthanhquang on 24 Aug 2020

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.

kcharwood on 24 Aug 2020

👍2

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.

calvinwkl on 24 Aug 2020

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

pigfly on 25 Aug 2020

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.

agiokas on 25 Aug 2020

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

tranthanhquang on 25 Aug 2020

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?

panderssanders on 25 Aug 2020

👍1

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.

grzegorzkrukowski on 26 Aug 2020

@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
```#!/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 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 "$@"
```

liuxuan30 on 27 Aug 2020

❤17 👍4

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.

liuxuan30 on 27 Aug 2020

👎6

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.

ThePragmaticArt on 27 Aug 2020

Screen Shot 2020-08-28 at 11 59 17 AM
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

lilpit on 28 Aug 2020

👍9

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

loganblevins on 28 Aug 2020

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

1oo7 on 28 Aug 2020

@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.

simonpierreroy on 28 Aug 2020

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?

1oo7 on 9 Sep 2020

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.

zulfishah on 10 Sep 2020

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.

marc-scig on 10 Sep 2020

👍7

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

ddaddy on 11 Sep 2020

👍5

@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 ?

dthientruc on 14 Sep 2020

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

ddaddy on 14 Sep 2020

@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.

rastersize on 14 Sep 2020

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. ☠️

jeffctown on 14 Sep 2020

@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...?

nicolas-miari on 15 Sep 2020

@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 ?

dthientruc on 15 Sep 2020

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

sjmorrow on 15 Sep 2020

Seems GM still contains this problem 😭

hiragram on 15 Sep 2020

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, https://github.com/Carthage/Carthage/issues/3019#issuecomment-676487951. Also, this is why disabling arm_64 for simulator builds makes the issue go way! (not a long term solution!)

simonpierreroy on 15 Sep 2020

👍8 ❤6

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 "$@"

hansemannn on 15 Sep 2020

👍19 ❤8

@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 😀

ghost on 16 Sep 2020

👍1

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

nicolas-miari on 16 Sep 2020

@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...

yhkaplan on 16 Sep 2020

👍11

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?

alexandre-g on 16 Sep 2020

😕1

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

bukira on 16 Sep 2020

@bukira Please read https://github.com/Carthage/Carthage/issues/3019#issuecomment-692954907. Thanks

ricardopereira on 16 Sep 2020

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

bukira on 16 Sep 2020

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

tmspzz on 16 Sep 2020

but no cathage build with this in?

bukira on 16 Sep 2020

but no cathage build with this in?

This workaround is not suitable for Carthage itself.

tmspzz on 16 Sep 2020

is there a plan moving forward?

bukira on 16 Sep 2020

xcframewoks https://github.com/Carthage/Carthage/pull/2881

tmspzz on 16 Sep 2020

@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.

mmdumi on 16 Sep 2020

xcframewoks #2881

and what's that?

bukira on 16 Sep 2020

@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.

tmspzz on 16 Sep 2020

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

bukira on 16 Sep 2020

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.

mmdumi on 16 Sep 2020

👍2

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

marinofaggiana on 16 Sep 2020

👍2

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

cherryworks on 16 Sep 2020

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.

dthientruc on 16 Sep 2020

👍5

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

bukira on 16 Sep 2020

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.

tibo9 on 16 Sep 2020

👍3 ❤1

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

marinofaggiana on 16 Sep 2020

This is just sad. There's no response or even notion of progress here. This is probably the highest priority item Carthage has had to have addressed in years... It basically sounds like Carthage is dead.

ThePragmaticArt on 16 Sep 2020

When I build with cocoapods I get error warning as well, it still seems to build but warns, bot confirmed if the end result works thou, so same cocopods also has the same issues

bukira on 16 Sep 2020

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.

Thank you for your answer! It's works for me.

tranthanhquang on 16 Sep 2020

This is just sad. There's no response or even notion of progress here. This is probably the highest priority item Carthage has had to have addressed in years... It basically sounds like Carthage is dead.

Ok, I'll bite.

I hope you all understand that there are no such things as "Carthage Developers". No-one is payed to work on Carthage and it's a totally volunteer based project. So expecting fixes or progress to just drop from nowhere is, to put it mildly, unrealistic.

I just so happened to get involved by contributing my own time on a fairly regular basis. I've tried to keep things running at the best of my ability and time I can commit. I apologise to the community if this isn't working out. I myself admit that I don't have all the answers and are not able to fix all issues. I would like to, but I just can't.

At the moment I don't have enough spare time to address this particular issue. Many people have asked me before what needed to be done to progress the xcframework branch #2881 and I have been happy to provide guidance as much as possible in private (or on the PR). I'm happy to continue doing so if anyone wants to take it further.

I don't know about the personal situation of other maintainers but I do know that some people that used to contribute can't anymore because of their employer.

Carthage is alive as much as people are willing/can to contribute to it. And yes, not all PRs are merged in a timely fashion because of stability/security/impact concerns. I deeply apologise for that but that's just the way it is.

Now then, what do I suggest people do in this particular instance?

Stop using abusing this issue with no-so-relevant comments. People come here for solutions and shouldn't have to wade through comments.
If you're not building for Apple Silicon this workaround should be totally fine and __should__ work for all libraries. If it doesn't I strongly recommend investigating on your own. The workaround just prevents a particular platform from being built, nothing more.
As long as you can still use Xcode 11, you're fine and should not worry about this.
Contribute to be the best of your ability to the project. See #2881 and feel free to contact me on twitter
Make working on carthage financially viable for volunteers

I hope you all understand that this is posted with the best intentions. I am very grateful to everyone that contributes by opening issues, fixing bugs and caring about the project.

tmspzz on 16 Sep 2020

❤72 👍51

This is just sad. There's no response or even notion of progress here. This is probably the highest priority item Carthage has had to have addressed in years... It basically sounds like Carthage is dead.

Ok, I'll bite.

I hope you all understand that there are no such things as "Carthage Developers". No-one is payed to work on Carthage and it's a totally volunteer based project. So expecting fixes or progress to just drop from nowhere is, to put it mildly, unrealistic.

I just so happened to get involved by contributing my own time on a fairly regular basis. I've tried to keep things running at the best of my ability and time I can commit. I apologise to the community if this isn't working out. I myself admit that I don't have all the answers and are not able to fix all issues. I would like to, but I just can't.

At the moment I don't have enough spare time to address this particular issue. Many people have asked me before what needed to be done to progress the xcframework branch #2881 and I have been happy to provide guidance as much as possible in private (or on the PR). I'm happy to continue doing so if anyone wants to take it further.

I don't know about the personal situation of other maintainers but I do know that some people that used to contribute can't anymore because of their employer.

Carthage is alive as much as people are willing/can to contribute to it. And yes, not all PRs are merged in a timely fashion because of stability/security/impact concerns. I deeply apologise for that but that's just the way it is.

Now then, what do I suggest people do in this particular instance?

Stop using abusing this issue with no-so-relevant comments. People come here for solutions and shouldn't have to wade through comments.

If you're not building for Apple Silicon this workaround should be totally fine and __should__ work for all libraries. If it doesn't I strongly recommend investigating on your own. The workaround just prevents a particular platform from being built, nothing more.

As long as you can still use Xcode 11, you're fine and should not worry about this.

Contribute to be the best of your ability to the project. See #2881 and feel free to contact me on twitter

Make working on carthage financially viable for volunteers

I hope you all understand that this is posted with the best intentions. I am very grateful to everyone that contributes by opening issues, fixing bugs and caring about the project.

The problem isn't a lack of understanding of the project being open sourced. It's the sheer lack of transparency and predictability on the project roadmap with what seems to be an unpredictable timeline for time sensitive features. Carthage is a dependency manager which is a core part of any project. If we can't rely on the community to correct a critical issue like this over the course of 4-6 months, what does this say about using this toolset for Fortune 100/500 company projects? As far as I can tell, Carthage is dead and the direction of the project is to go to SPM (which I'm happy in doing where ever I can). Work around hacks are bandages and I cannot encourage implementing that in critical projects as a "solution". Heck, if that workaround is reliable enough, why not implement it via a pr into the main repo 😒.

ThePragmaticArt on 16 Sep 2020

👍7 ❤1 👎1

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.

I had tried to build xcframework and replace dependencies with "absolute file path" ones in the project Package.resolved to have CI build quickest as possible:

$ diff ./ConsumeSKViaXcode.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved
{
  "object": {
    "pins": [
      {
        "package": "SPMBinaryDep",
-        "repositoryURL": "https://github.com/openium/SPMBinaryDep",
+        "repositoryURL": "/Users/kenji/Desktop/SPMBinaryDep",
        "state": {
          "branch": null,
          "revision": "f03b511c2d966805070e97df469139836ada2498",
          "version": "1.0.1"
        }
      }
    ]
  },
  "version": 1
}

So you should clone all packages, then list platforms for each :

$ swift package dump-package | jq '.platforms | map(.platformName) | unique | join(";")'
macos;ios

Then you can xcodebuild archive in a loop, and lastly xcodebuild -create-xcframework them.

kenji21 on 16 Sep 2020

@ThePragmaticArt

The problem isn't a lack of understanding of the project being open sourced. It's the sheer lack of transparency and predictability on the project roadmap with what seems to be an unpredictable timeline for time sensitive features.

Again, it's a community driven project. The is no "secret committee" making roads maps and all discussions happen here and occasionally on twitter/slack. Here is a tentative roadmap __I__ made after a quick consultation https://github.com/Carthage/Carthage/issues/2890

what does this say about using this toolset for Fortune 100/500 company projects?

What does it tell about Fortune 500 companies not contributing or supporting the project?

the direction of the project is to go to SPM

It is indeed the direction to go.

Apple controls:

The hardware
The operating system
The tools
The distribution channels

It's utterly unrealistic to expect that the community can keep up.

This is the last comment I'm going to make about this, because nothing productive will come out of it.

tmspzz on 16 Sep 2020

👍32 ❤21 👎1

@tmspzz Absolutely agreeing with you! I know how frustrating it can be if everyone just leeches the software for free but doesn't even consider sponsoring / contributing to it. Maybe you or another maintainer can setup GitHub Sponsors / Patreon and every commenter here contributes a bit. Thank you for all the effort you and other Carthage maintainers put into this project! 🔥

hansemannn on 16 Sep 2020

❤17

I modified the script to be able to pass the desired command to it and to be able to include the x86_64 architecture, since in XCode 12 it generates it as arm64 (Apple Silicon, I understand)

# 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 2
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
echo 'ONLY_ACTIVE_ARCH=NO' >> $xcconfig
echo 'VALID_ARCHS = $(inherited) x86_64' >> $xcconfig
export XCODE_XCCONFIG_FILE="$xcconfig"
echo $XCODE_XCCONFIG_FILE
carthage "$@"

I ran the following command

/carthage-build.sh build --platform iOS --no-use-binaries libPhoneNumber-iOS

and I generated the framework with all the architectures that I need

lipo -info Carthage/Build/iOS/libPhoneNumberiOS.framework/libPhoneNumberiOS

architectures in the fat file: Carthage/Build/iOS/libPhoneNumberiOS.framework/libPhoneNumberiOS are: armv7 i386 x86_64 arm64

oscarcv on 16 Sep 2020

👍27 ❤6 🎉5

does the XCODE_XCCONFIG_FILE need to be exported? Wouldnt it be enought to run as XCODE_XCCONFIG_FILE="$xcconfig" carthage "$@"?

zdnk on 16 Sep 2020

I'm getting stuck when trying to execute the workaround steps.
how do I apply this workaround? https://github.com/Carthage/Carthage/issues/3019#issuecomment-665136323

I'm in this folder /usr/local/lib/node_modules/appium/node_modules/appium-webdriveragent

what do I do here? do I modify the /Scripts/bootstrap.sh file or do I create a new file, and where?

many thanks in advance!

shaky on 16 Sep 2020

Is it possible this issue could cause code signing issues resulting in Unable to install [App] when trying to run on a device? I was able to complete carthage update with the carthage-build.sh shared in this thread and our project builds successfully in Xcode, but on the last step when copying to a device: No code signature found

The app works fine in the simulator, and it looks like all the right stuff is in the build logs:

export EXPANDED_CODE_SIGN_IDENTITY\=0D3D**************************************8DE
export EXPANDED_CODE_SIGN_IDENTITY_NAME\=Apple\ Development:\ Samuel\ Mueller\ \(FR************\)
export EXPANDED_PROVISIONING_PROFILE\=77dbffef-2667-4985-*****-**************

The issue only cropped up after upgrading to Xcode 12 and running carthage with this build script.

sjmueller on 16 Sep 2020

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.

Sorry to be dense, but where exactly do I put this fix? (I am NOT on the new Apple hardware; plain ol' Retina MacBook Pro.)

meadowsr on 16 Sep 2020

@shaky @meadowsr You have to create a wrapper to invoke carthage like so:

https://github.com/Carthage/Carthage/issues/3019#issuecomment-693381253

tmspzz on 16 Sep 2020

👍1

Carthage has just updated to 0.35.1, so this version has fixed the issue ? When i saw new update from Carthage on Github, i didn't see anything mention about it.

dthientruc on 17 Sep 2020

Carthage has just updated to 0.35.1, so this version has fixed the issue ? When i saw new update from Carthage on Github, i didn't see anything mention about it.

It doesn’t contain a fix for this issue (see the top call out in the release notes). The only fix for this is XCFrameworks, for which there is an open - not yet finished - PR.

rastersize on 17 Sep 2020

👍12

@oscarcv can you please provide some steps where that script should live? (https://github.com/Carthage/Carthage/issues/3019#issuecomment-693381253)
I just touch it here? /usr/local/lib/node_modules/appium/node_modules/appium-webdriveragent ?

Thanks!

shaky on 17 Sep 2020

@oscarcv can you please provide some steps where that script should live? (#3019 (comment))
I just touch it here? /usr/local/lib/node_modules/appium/node_modules/appium-webdriveragent ?

Thanks!

@shaky i never use appium,sorry.

If you paste the carthage command that you run here, maybe I can tell you how to run it

oscarcv on 17 Sep 2020

See here https://github.com/Carthage/Carthage/issues/3019#issuecomment-690755581
Just put it in the same folder as your Cartfile.

ddaddy on 17 Sep 2020

👍2

To speed up wrapper integration in scripts while waiting for permanent solution: https://gist.github.com/skymobilebuilds/61f4a95bd62a3db36b52719aeab7e0d5

skymobilebuilds on 17 Sep 2020

👍28

@skymobilebuilds nice. Please provide a sha256 checksum so that people can confirm the file is unaltered.

tmspzz on 17 Sep 2020

@tmspzz added sha256 in the gist!

skymobilebuilds on 17 Sep 2020

To speed up wrapper integration in scripts while waiting for permanent solution: https://gist.github.com/skymobilebuilds/61f4a95bd62a3db36b52719aeab7e0d5

Nice ! However, Will apple reject my apps from the store ? I'm scared of that.

leminhcse on 18 Sep 2020

I'm facing this issue with Alamofire using the workaround script linked above:

Module 'Alamofire' was created for incompatible target arm64-apple-ios10.0

When trying to run on simulator device.
This is used inside a framework code.
If I choose to run on a generic iOS device, everything works fine.
If I choose to run an app which integrates the framework on a simulator, everything works.

Any suggestions?

TheSpartan94 on 18 Sep 2020

👍1

I created a script from this comment https://github.com/Carthage/Carthage/issues/3019#issuecomment-665136323 , but when I try to run it ./carthage-build.sh update --platform iOS, I get the following error "env: bash\r\r: No such file or directory". How can I fix it?

MegakoMar on 18 Sep 2020

@MegakoMar I had the same issue. This worked for me sh carthage-build.sh build --platform iOS

nathanbroyles on 18 Sep 2020

Same for me with the final released Xcode 12 (and Carthage 0.36.0)

JetForMe on 19 Sep 2020

I am using Xcode 12 (GM) and Carthage 0.36.0.
I faced an error when running "Carthage update --platform iOS" : "Task failed with exit code 1"
I have no idea how to solve this.
Please help me if you are good at this issue.

danielsGit on 19 Sep 2020

👍2

I am using Xcode 12 (GM) and Carthage 0.36.0.

I faced an error when running "Carthage update --platform iOS" : "Task failed with exit code 1"

I have no idea how to solve this.

Please help me if you are good at this issue.

Please read the comments in this issue. https://github.com/Carthage/Carthage/issues/3019#issuecomment-694329329

tmspzz on 19 Sep 2020

👍1

I'm facing this issue with Alamofire using the workaround script linked above:

Module 'Alamofire' was created for incompatible target arm64-apple-ios10.0

When trying to run on simulator device.
This is used inside a framework code.
If I choose to run on a generic iOS device, everything works fine.
If I choose to run an app which integrates the framework on a simulator, everything works.

Any suggestions?

Do you have VALID_ARCHS on your build setting? If yes, remove it and try again.

I have same issue yesterday, and solved by remove it.

Deprecations
The Build Settings editor no longer includes the Valid Architectures build setting (VALID_ARCHS), and its use is discouraged. Instead, there is a new Excluded Architectures build setting (EXCLUDED_ARCHS). If a project includes VALID_ARCHS, the setting is displayed in the User-Defined section of the Build Settings editor. (15145028)

The legacy build system is deprecated, and will be removed in a future release. (62742902)

https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes

hanksudo on 19 Sep 2020

👍1

was created for incompatible target arm64

hi， how to remove the "VALID_ARCHS" after I clear the value of it ,it will appear another problem "No architectures to compile for (ARCHS=arm64 x86_64, VALID_ARCHS=)."

houjianwen123 on 21 Sep 2020

I'm facing this issue with Alamofire using the workaround script linked above:
Module 'Alamofire' was created for incompatible target arm64-apple-ios10.0
When trying to run on simulator device.
This is used inside a framework code.
If I choose to run on a generic iOS device, everything works fine.
If I choose to run an app which integrates the framework on a simulator, everything works.
Any suggestions?

Do you have VALID_ARCHS on your build setting? If yes, remove it and try again.

I have same issue yesterday, and solved by remove it.
Deprecations
The Build Settings editor no longer includes the Valid Architectures build setting (VALID_ARCHS), and its use is discouraged. Instead, there is a new Excluded Architectures build setting (EXCLUDED_ARCHS). If a project includes VALID_ARCHS, the setting is displayed in the User-Defined section of the Build Settings editor. (15145028)

The legacy build system is deprecated, and will be removed in a future release. (62742902)
https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes

Your suggestion was really something else. I had no VALID_ARCHS set, but i solved the problem by setting "Build Active Architecture Only" to YES for all Configurations. Thank you.

TheSpartan94 on 21 Sep 2020

anyone has any luck to make a build for simulator with carthage? Trying to make our automation team happy. TIA!

sofili on 22 Sep 2020

Are there any core-team updates on this issue? As iOS 14 has been officially released, and there are more and more teams running into this, myself and I would assume others would love any updates on the status for a fix. E.g. if a fix is imminent, still being worked on, if it's unclear if the issue can be fixed at all, etc. Any clarity that you all can offer would be immensely appreciated!

chrismanderson on 23 Sep 2020

👍46

@chrismanderson see https://github.com/Carthage/Carthage/issues/3019#issuecomment-693324360

tmspzz on 23 Sep 2020

👍4

bump

denis-hoz on 24 Sep 2020

👎2

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.

To support this situation, I can also confirm to have this issue when compiling the project(after applying the workaround). In my case, it is a SwiftUI free project.
Than I tried to move the particular dependency to SPM. After that, the next dependency was failing with the same error
module 'Dependency' was created for incompatible target arm64-apple-ios9.0

odanu on 24 Sep 2020

The workaround works properly but some package remain problematic in Xcode even though the workaround appears to compile the fat framework properly.... A good example is libPhoneNumberiOS, which will trigger The linked framework .. is missing one or more architectures required by this target: x86_64 (cf https://github.com/iziz/libPhoneNumber-iOS/issues/317)

quentinfasquel on 24 Sep 2020

For the brave among you, you can try to build #2881 which is now in working shape again

To be eligible for xcframework builds a scheme must have BUILD_LIBRARY_FOR_DISTRIBUTION=YES and SKIP_INSTALL=NO

since most of the libraries I have tried don't support these settings out of the box, you will have to either pass a custom .xcconfig or, first run carthage bootstrap --no-build --no-use-binaries and then change the above mentioned settings manually.

To build as xcframeworks run

carthage build --create-xcframework combined --no-use-binaries

.version files don't work
binary downloads of xcframewroks don't work

Please report other issues on the PR, not here. Thanks.

tmspzz on 24 Sep 2020

❤8

i added tmp.xcconfig, but still have the following error:

Failed to write to /Users/userName/projectName/Carthage/Build/iOS/Alamofire.framework: Error Domain=NSCocoaErrorDomain Code=260 "The file “Alamofire.framework” couldn’t be opened because there is no such file." UserInfo={NSURL=file:///Users/userName/projectName//Carthage/Checkouts/Alamofire/build/ArchiveIntermediates/Alamofire%20iOS/BuildProductsPath/Release-iphoneos/Alamofire.framework, NSFilePath=/Users/userName/projectName/Carthage/Checkouts/Alamofire/build/ArchiveIntermediates/Alamofire iOS/BuildProductsPath/Release-iphoneos/Alamofire.framework, NSUnderlyingError=0x7f92ef65e1c0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

MichaelLuoSyd on 25 Sep 2020

For anyone getting project compile errors like Module 'xxx' was created for incompatible target arm64-apple-ios9.0 after applying the workaround, there is one thing to be done, to fix it.
Exclude arm64 from every scheme for iOS Simluator SDK, inside your target.

Screenshot 2020-09-25 at 15 13 21

odanu on 25 Sep 2020

👍8 🎉2 👀1

Trying the collective wisdom - anyone successfully made a script for building libraries for simulator only?

sofili on 25 Sep 2020

@rastersize suggestion to handle whatever xcode version is installed:

```#!/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 make sure EXCLUDED_ARCHS is set to arm architectures otherwise

the build will fail on lipo due to duplicate architectures.

CURRENT_XCODE_VERSION=$(xcodebuild -version | grep "Build version" | cut -d' ' -f3)
echo "EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$CURRENT_XCODE_VERSION = 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"
carthage build "$@"

vitormf on 25 Sep 2020

👍30 🎉14

Here is a lane definition for fastlane if anyone wants to use it:

  desc "Run carthage in a wrapper that works with Xcode 12"
  lane :carthage_wrapper do |options|
    require 'tempfile'
    tmp = Tempfile.new('xcconfig')
    oldXcconfig = ENV['XCODE_XCCONFIG_FILE']
    ENV['XCODE_XCCONFIG_FILE'] = tmp.path
    begin
      tmp.write("EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8\n")
      tmp.write("EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))\n")
      tmp.flush

      carthage(options)
    ensure
      # Always delete the temp file
      tmp.close
      tmp.unlink
      ENV['XCODE_XCCONFIG_FILE'] = oldXcconfig
    end
  end

I do not know if there actually is a previous value of the environment variable that needs to be put back, but you do need to unset the environment variable otherwise your app build may fail - I'm not sure why that is though.

kohenkatz on 25 Sep 2020

👍7

@vitormf Thanks for the suggestion, that made me re-evaluate the script.

Now that Xcode 12 is out of beta an no-one should be using beta 1 or 2 anymore we can simplify it even more. Specifically, we can opt all Xcode 12 versions into the workaround. I’ve updated my comment with an updated script.

rastersize on 26 Sep 2020

👍2

Looks like the .sh scripts no longer work for Xcode 12.0.1

mmoloksher on 29 Sep 2020

👍4 👀1

Run this down (because this is largely untested), but the following xcconfig should behave correctly on all current and future Xcodes:

NON_BLANK_FOR_XCODE_VERSION_MAJOR_0100=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0200=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0300=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0400=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0500=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0600=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0700=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0800=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0900=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_1000=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_1100=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_0000=YES
NON_BLANK_FOR_XCODE_PRODUCT_BUILD_VERSION_12A6159=YES
NON_BLANK_FOR_XCODE_PRODUCT_BUILD_VERSION_12A6163b=YES
NON_BLANK_FOR_XCODE_VERSION_MAJOR_1200=$(NON_BLANK_FOR_XCODE_PRODUCT_BUILD_VERSION_$(XCODE_PRODUCT_BUILD_VERSION))
THIS_SPOT_LEFT_BLANK_IF_XCODE_12_OR_HIGHER=$(NON_BLANK_FOR_XCODE_VERSION_MAJOR_$(XCODE_VERSION_MAJOR))
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__THIS_SPOT_LEFT_BLANK_IF_XCODE_12_OR_HIGHER___NATIVE_ARCH_64_BIT_x86_64=arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS=$(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)__THIS_SPOT_LEFT_BLANK_IF_XCODE_12_OR_HIGHER_$(THIS_SPOT_LEFT_BLANK_IF_XCODE_12_OR_HIGHER)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT))
// `NON_BLANK_FOR_XCODE_VERSION_MAJOR_1200` is kind of mis-named ⇢ it works around some early Xcode 12 betas (the two listed) that have a bug with `EXCLUDED_ARCHS`
// Mass expectation is those two Xcodes exhaust the set of ever-to-be-published Xcodes that hit the `EXCLUDED_ARCHS` bug.

jdhealy on 29 Sep 2020

👍1

@mmoloksher The workaround script in my comment above _should_ work for all versions of Xcode (11.x, 12.x etc.). It was updated a few days ago with that in mind.

rastersize on 29 Sep 2020

@rastersize Unfortunately it does not, in fact with Xcode 12.0.1 installed, running ./carthage-build.sh --platform iOS in the terminal results in Unrecognized arguments: --platform. It was working for Xcode 12.0 however.
This version of the script seems to actually work for Xcode 12.0.1

mmoloksher on 29 Sep 2020

@mmoloksher The script was updated so that you need to tell it what action you want to take. So you’ll need to update the invocation to ./carthage-build.sh build --platform iOS.

Sorry for the confusion. This is to allow it to be used with the bootstrap and update commands as well. For those that don’t separate out the build step.

rastersize on 29 Sep 2020

👍1

@rastersize Thank you, I guess I missed that part. I can confirm your script works on Xcode 12.0.1

mmoloksher on 29 Sep 2020

❤2 🎉2

Thanks @kohenkatz, your workaround worked for me on Xcode 12.0.1 ❤️

vixentael on 29 Sep 2020

Using the script doesn't seem to help with the issue on my end — still getting build failed in the terminal with Carthage and in Xcode getting:

Building for iOS Simulator, but the linked framework 'Foo.framework' was built for iOS."

simonbromberg on 30 Sep 2020

I was able to use the script for one project, but another that uses the OneSignal SDK doesn't work. That SDK fails to build:

CompileC /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/Objects-normal/x86_64/OSTrackerFactory.o /Users/rmann/Projects/Personal/MissionClock/repo/MissionClock/Carthage/Checkouts/OneSignal-iOS-SDK/iOS_SDK/OneSignalSDK/Source/OSTrackerFactory.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler (in target 'OneSignalFramework' from project 'OneSignal')
    cd /Users/rmann/Projects/Personal/MissionClock/repo/MissionClock/Carthage/Checkouts/OneSignal-iOS-SDK/iOS_SDK/OneSignalSDK
    export LANG\=en_US.US-ASCII
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -target x86_64-apple-ios8.0 -fmessage-length\=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit\=0 -std\=gnu99 -fobjc-arc -fmodules -gmodules -fmodules-cache-path\=/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/ModuleCache.noindex -fno-autolink -fmodules-prune-interval\=86400 -fmodules-prune-after\=345600 -fbuild-session-file\=/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/ModuleCache.noindex/Session.modulevalidation -fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module -Werror\=non-modular-include-in-framework-module -fmodule-name\=OneSignal -Wno-trigraphs -fpascal-strings -Os -fno-common -Wno-missing-field-initializers -Wno-missing-prototypes -Werror\=return-type -Wdocumentation -Wunreachable-code -Wno-implicit-atomic-properties -Werror\=deprecated-objc-isa-usage -Wno-objc-interface-ivars -Werror\=objc-root-class -Wno-arc-repeated-use-of-weak -Wduplicate-method-match -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wundeclared-selector -Wno-deprecated-implementations -DNS_BLOCK_ASSERTIONS\=1 -DOBJC_OLD_DISPATCH_PROTOTYPES\=0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.0.sdk -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-semicolon-before-method-body -iquote /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/OneSignal-generated-files.hmap -I/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/OneSignal-own-target-headers.hmap -I/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/OneSignal-all-non-framework-target-headers.hmap -ivfsoverlay /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/all-product-headers.yaml -iquote /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/OneSignal-project-headers.hmap -I/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/BuildProductsPath/Release-iphoneos/include -I/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/DerivedSources-normal/x86_64 -I/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/DerivedSources/x86_64 -I/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/DerivedSources -F/Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/BuildProductsPath/Release-iphoneos -fembed-bitcode -MMD -MT dependencies -MF /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/Objects-normal/x86_64/OSTrackerFactory.d --serialize-diagnostics /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/Objects-normal/x86_64/OSTrackerFactory.dia -c /Users/rmann/Projects/Personal/MissionClock/repo/MissionClock/Carthage/Checkouts/OneSignal-iOS-SDK/iOS_SDK/OneSignalSDK/Source/OSTrackerFactory.m -o /Users/rmann/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0.1_12A7300/OneSignal-iOS-SDK/2.15.3/Build/Intermediates.noindex/ArchiveIntermediates/OneSignalFramework/IntermediateBuildFilesPath/OneSignal.build/Release-iphoneos/OneSignalFramework.build/Objects-normal/x86_64/OSTrackerFactory.o
While building module 'Foundation' imported from /Users/rmann/Projects/Personal/MissionClock/repo/MissionClock/Carthage/Checkouts/OneSignal-iOS-SDK/iOS_SDK/OneSignalSDK/Source/OSTrackerFactory.m:28:
While building module 'CoreFoundation' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6:
While building module 'Darwin' imported from /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.0.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:
In file included from <module-includes>:1:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.0.sdk/usr/include/sys/cdefs.h:814:2: error: Unsupported architecture
#error Unsupported architecture
 ^

JetForMe on 30 Sep 2020

The workaround works properly but some package remain problematic in Xcode even though the workaround appears to compile the fat framework properly.... A good example is libPhoneNumberiOS, which will trigger The linked framework .. is missing one or more architectures required by this target: x86_64 (cf iziz/libPhoneNumber-iOS#317)

Made a specific fix for this issue here: https://github.com/iziz/libPhoneNumber-iOS/issues/317#issuecomment-701474959.

This assumes you already applied https://github.com/Carthage/Carthage/issues/3019#issuecomment-665136323

jrabek on 30 Sep 2020

That’s why I forked that repo as it doesn’t support all architectures, missing key Settings, mine builds fine using the script

On 30 Sep 2020, at 17:15, Jesse Rabek notifications@github.com wrote:

The workaround works properly but some package remain problematic in Xcode even though the workaround appears to compile the fat framework properly.... A good example is libPhoneNumberiOS, which will trigger The linked framework .. is missing one or more architectures required by this target: x86_64 (cf iziz/libPhoneNumber-iOS#317)

Made a specific fix for this issue here: iziz/libPhoneNumber-iOS#317 (comment).

This assumes you already applied #3019 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

bukira on 30 Sep 2020

@odanu

For anyone getting project compile errors like Module 'xxx' was created for incompatible target arm64-apple-ios9.0 after applying the workaround, there is one thing to be done, to fix it.
Exclude arm64 from every scheme for iOS Simluator SDK, inside your target.
...

Thank you for posting this.

drewolbrich on 2 Oct 2020

What are the plans for releasing a new version of Carthage that doesn't need the hot fix script?

sushant40 on 5 Oct 2020

👍18

@sushant40 please read the comments in this issue.

tmspzz on 5 Oct 2020

@tmspzz none of the comments in this issue says whether Carthage plans to address this or not. Instead there's now hundreds of projects applying a workaround several weeks after Xcode 12 GM was released.

And the issue was created over two months ago. It really seems like someone dropped the ball here.

clausjoergensen on 5 Oct 2020

👎2

@tmspzz none of the comments in this issue says whether Carthage plans to address this or not. Instead there's now hundreds of projects applying a workaround several weeks after Xcode 12 GM was released.

And the issue was created over two months ago. It really seems like someone dropped the ball here.

🤦‍♂️

tmspzz on 5 Oct 2020

👎1

@clausjoergensen some of those comments say that it will be solved by implementing support of XCFrameworks (#2881, #2801)

olejnjak on 5 Oct 2020

👍1

Indeed, xcframework comes as the official solution to distribute
multi-platform / multi-architecture libraries or framework. In particular,
lipo can embed several architecture but cannot handle several similar
architecture for different platforms. This case existed with watchOS in the
past and with future Macs that will have iOS simulator in arm64. Lipo was
never an official solution but never caused any problem. Today , with
Xcode12, xcframework becomes necessary.

On Mon 5 Oct 2020 at 18:51, Jakub Olejník notifications@github.com wrote:

>
>

@clausjoergensen https://github.com/clausjoergensen some of those
comments say that it will be solved by implementing support of XCFrameworks
(#2881 https://github.com/Carthage/Carthage/pull/2881, #2801
https://github.com/Carthage/Carthage/pull/2801)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Carthage/Carthage/issues/3019#issuecomment-703755250,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEFE6KOIAVRRIVQUMOD4S3SJH2QPANCNFSM4PFKOINA
.

--
Sent from Gmail Mobile

quentinfasquel on 5 Oct 2020

But this means that third parties have to support xcframeworks in their repos? And most don’t that I can see unless I am wrong ?

On 5 Oct 2020, at 18:14, Quentin notifications@github.com wrote:

Indeed, xcframework comes as the official solution to distribute
multi-platform / multi-architecture libraries or framework. In particular,
lipo can embed several architecture but cannot handle several similar
architecture for different platforms. This case existed with watchOS in the
past and with future Macs that will have iOS simulator in arm64. Lipo was
never an official solution but never caused any problem. Today , with
Xcode12, xcframework becomes necessary.

On Mon 5 Oct 2020 at 18:51, Jakub Olejník notifications@github.com wrote:

>
>

@clausjoergensen https://github.com/clausjoergensen some of those
comments say that it will be solved by implementing support of XCFrameworks
(#2881 https://github.com/Carthage/Carthage/pull/2881, #2801
https://github.com/Carthage/Carthage/pull/2801)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Carthage/Carthage/issues/3019#issuecomment-703755250,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEFE6KOIAVRRIVQUMOD4S3SJH2QPANCNFSM4PFKOINA
.

--
Sent from Gmail Mobile
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

bukira on 5 Oct 2020

I also had a bunch of could not build module 'CocoaAsyncSocket' errors with Xcode 12 and Appium 1.18.2 when trying to build my WebDriverAgent project onto an iPhone with the following command:

xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination 'id=<udid>' test

Solution
As mentioned, install appium@beta (1.19.0-beta.0 at the time of writing)

nimaiwalsh on 7 Oct 2020

@bukira Not really. Third parties don't need to support xcframework for carthage to support them properly.
Carthage comes as a build machine for any project that builds a static library or a framework. The same way it was able to create a fat-library or fat-framework from your project, it will be able to build a xcframework of that library or framework.

What you say is relevant if the third party is distributed as a binary :

Either it was distributed as a fat-binary -> they should now distribute an xcframework (anyone can manually unfat a binary and create an xcframework, its quick and easy)
Or it was distributed as multiple binaries (for each architecture) -> they should create an xcframework as a "holder" of these binaries and distribute it this way.

XCFramework is confusing in its name, it can hold "Static Library + Headers" or "Frameworks", and technically I believe that one XCFramework could hold multiple libraries or frameworks. XCFramework is not a built product, it is a package of already built products.

quentinfasquel on 7 Oct 2020

Thanks for that, so I can install the current version of Carthage, and use it to create XCFrameworks from any project, and use no-use-binary for those that disturb as binary?

If so how?

I can then add the XCFrameworks as dependencies of my SPM packages by hosting the XCFrameworks myself and updating them as and when needed

So I dont run Carthage update/bootstrap but a different command to create XCFrameworks?

On 7 Oct 2020, at 14:56, Quentin notifications@github.com wrote:

@bukira https://github.com/bukira Not really. Third parties don't need to support xcframework for carthage to support them properly.
Carthage comes as a build machine for any project that builds a static library or a framework. The same way it was able to create a fat-library or fat-framework from your project, it will be able to build a xcframework of that library or framework.

What you say is relevant if the third party is distributed as a binary :

Either it was distributed as a fat-binary -> they should now distribute an xcframework (anyone can manually unfat a binary and create an xcframework, its quick and easy)
Or it was distributed as multiple binaries (for each architecture) -> they should create an xcframework as a "holder" of these binaries and distribute it this way.
XCFramework is confusing in its name, it can hold "Static Library + Headers" or "Frameworks", and technically I believe that one XCFramework could hold multiple libraries or frameworks. XCFramework is not a built product, it is a package of already built products.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Carthage/Carthage/issues/3019#issuecomment-704953553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXG63YZA66NZUNLPDROKDSJRXRHANCNFSM4PFKOINA.

bukira on 7 Oct 2020

@bukira Not really. Third parties don't need to support xcframework for carthage to support them properly.
Carthage comes as a build machine for any project that builds a static library or a framework. The same way it was able to create a fat-library or fat-framework from your project, it will be able to build a xcframework of that library or framework.

What you say is relevant if the third party is distributed as a binary :

Either it was distributed as a fat-binary -> they should now distribute an xcframework (anyone can manually unfat a binary and create an xcframework, its quick and easy)

Or it was distributed as multiple binaries (for each architecture) -> they should create an xcframework as a "holder" of these binaries and distribute it this way.

XCFramework is confusing in its name, it can hold "Static Library + Headers" or "Frameworks", and technically I believe that one XCFramework could hold multiple libraries or frameworks. XCFramework is not a built product, it is a package of already built products.

So can anyone tell me then how to make an XCframework with Carthage as I can see any documentation on it

bukira on 9 Oct 2020

😕1

@bukira https://github.com/Carthage/Carthage/issues/3019#issuecomment-698553292

tmspzz on 9 Oct 2020

@bukira #3019 (comment)

Thank you very much, and this goes back to my previous comment that
"Third party must support this, by turning BUILD_LIBRARY_FOR_DISTRIBUTION=YES and SKIP_INSTALL=NO" this on in their shared schemes, can do manually but means after every checkout you have to edit the source

bukira on 9 Oct 2020

Any way to take an existing .framework and convert to XCFramework without the source code?

bukira on 9 Oct 2020

@bukira according to WWDC those two flags are required to support XCFrameworks. As I said you can bypass it by using a custom .xcconfig. Also, since you're building from source, you can edit carthage and just return true for those flags.

I don't know exactly what are the consequence of not respecting these flags, if anyone knows or has some documentation as of why they are needed please come forward.

Any way to take an existing .framework and convert to XCFramework without the source code?

If it's not a fat binary you can just use Xcode to repackage it. I don't know if it works for fat binaries as well.

tmspzz on 9 Oct 2020

For the brave among you, you can try to build #2881 which is now in working shape again

To be eligible for xcframework builds a scheme must have BUILD_LIBRARY_FOR_DISTRIBUTION=YES and SKIP_INSTALL=NO

since most of the libraries I have tried don't support these settings out of the box, you will have to either pass a custom .xcconfig or, first run carthage bootstrap --no-build --no-use-binaries and then change the above mentioned settings manually.

To build as xcframeworks run
carthage build --create-xcframework combined --no-use-binaries
.version files don't work

binary downloads of xcframewroks don't work

Please report other issues on the PR, not here. Thanks.

How do I build this version of Carthage?

bukira on 9 Oct 2020

@bukira please refer to the project's Readme. https://github.com/Carthage/Carthage#installing-carthage

tmspzz on 9 Oct 2020

Swift frameworks built with BUILD_LIBRARY_FOR_DISTRIBUTION=NO can't be repackaged into a xcframework because they don't have swiftinterface files. xcodebuild -create-xcframework rejects frameworks without that, and if you manually assemble one then Xcode will fail to consume it.

tgoyne on 9 Oct 2020

👍2

Once compiled dependencies with mentioned workaround, does anyone has an issue with running compiled app with dependencies with Xcode 12?
I get this, when I try to run on the real device. It works well on the simulator.

Details

Could not launch "AppName”
Domain: IDEDebugSessionErrorDomain
Code: 3
Failure Reason: No such file or directory (/Users/dmytrobrovkin/Library/Developer/Xcode/DerivedData/AppName-cexghllteovlzibuayyyhkekbvdi/Build/Products/Debug-DEV-ProjectH-iphoneos/AppName.app/AppName)
User Info: {
DVTRadarComponentKey = 855031;
RawLLDBErrorMessage = "No such file or directory (/Users/dmytrobrovkin/Library/Developer/Xcode/DerivedData/AppName-cexghllteovlzibuayyyhkekbvdi/Build/Products/Debug-DEV-ProjectH-iphoneos/AppName.app/AppName)";
}

DmytroBrovkin on 9 Oct 2020

That’s weird, because it’s complaining about the app, not a framework.

jrtibbetts on 9 Oct 2020

@grzegorzkrukowski Did your workaround work for watchOS?

I am running into an issue with the watchOS sim:

Could not find module 'Core' for target 'arm64-apple-watchos-simulator'; found: x86_64-apple-watchos-simulator, i386, i386-apple-watchos-simulator, x86_64, arm64_32-apple-watchos, armv7k, armv7k-apple-watchos, arm, arm64_32

marknorgren on 10 Oct 2020

@mrkd - my build fails for watchOS sim as well using the above workaround. The error is the same

plamenterziev on 10 Oct 2020

So with latest Xcode 12.0.1 from App store i am facing the same dreaded have the same architectures (arm64) and can't be in the same fat output file issue :(

az-oolloow on 12 Oct 2020

Has anyone checked with xCode 12.1 GM?

inPhilly on 14 Oct 2020

Has anyone checked with xCode 12.1 GM?

Not yet, but as it supports Apple Sillicon Macs as all 12.x versions, it will be the same.

olejnjak on 14 Oct 2020

Has anyone checked with xCode 12.1 GM?

Not yet, but as it supports Apple Sillicon Macs as all 12.x versions, it will be the same.

Okay, thanks. I am nervous about using Carthage now... and I'm a little confused about what is happening. Is this something Carthage can fix on their end, and if so, why are they not fixing it? Should we be looking for something else to replace Carthage?

inPhilly on 14 Oct 2020

👍4

Has anyone checked with xCode 12.1 GM?

Not yet, but as it supports Apple Sillicon Macs as all 12.x versions, it will be the same.

Okay, thanks. I am nervous about using Carthage now... and I'm a little confused about what is happening. Is this something Carthage can fix on their end, and if so, why are they not fixing it? Should we be looking for something else to replace Carthage?

Just go through this issue, everything is written here...yes it can be fixed on Carthage side, work is in progress (#2881), but as you surely know, Carthage is opensource, there is nothing like Carthage team, that will only take care of it, people do that in their free time, after work, etc.

Replacing Carthage (especially with SPM) would probably be the only fully reliable solution as it is maintained by Apple, so they do have such dedicated team, even though it is OSS as well.

olejnjak on 14 Oct 2020

❤13

Is this supposed to work for Simulator builds on Intel? I'm trying the wrapper in this comment, but when I build my app for Simulator, I get "building for iOS Simulator, but linking in dylib built for iOS, file '.../repo/MyApp/Carthage/Build/iOS/OneSignal.framework/OneSignal' for architecture arm64"

JetForMe on 16 Oct 2020

Is this supposed to work for Simulator builds on Intel? I'm trying the wrapper in this comment, but when I build my app for Simulator, I get "building for iOS Simulator, but linking in dylib built for iOS, file '.../repo/MyApp/Carthage/Build/iOS/OneSignal.framework/OneSignal' for architecture arm64"

Make sure none of the Xcode project involved in your app includes "VALID_ARCHS" in target or project Build Settings. Then if required, add Build Setting EXCLUDED_ARCHS to be 'arm64' for "Any iOS simulator", in both Debug and Release. Indeed, Xcode12 doesn't care that you are on Intel and that arm64 simulator doesn't exist. It's trying to build simulator arm64, which is provided by no common frameworks, and mostly that cannot currently be provided by Carthage.

quentinfasquel on 17 Oct 2020

👍2

Make sure none of the Xcode project involved in your app includes "VALID_ARCHS" in target or project Build Settings. Then if required, add Build Setting EXCLUDED_ARCHS to be 'arm64' for "Any iOS simulator", in both Debug and Release. Indeed, Xcode12 doesn't care that you are on Intel and that arm64 simulator doesn't exist. It's trying to build simulator arm64, which is provided by no common frameworks, and mostly that cannot currently be provided by Carthage.

It took me a minute to understand what you were telling me to do, but I think I've got it working now. In my project (the Carthage dependencies have this set by the wrapper script above), I needed to clear VALID_ARCHS and set EXCLUDED_ARCHS like this:

Screen Shot 2020-10-17 at 16 43 17

This is probably better done with an xcconfig file but I have never learned how to properly use those. In that case, the line looks something like EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64.

Can it be argued that this is a bug in Xcode 12? It sure seems so to me. Plenty of old projects won't have this exclusion, and Xcode shouldn't include it by default if it can't build it.

FWIW, I filed Radar 8809063 against Xcode, suggesting it not build arm64/sim by default on an Intel Mac. I suggest others do the same (assuming I'm not wrong about this). Here's the bulk of my bug report:

Context: Catalina on an Intel Mac.

The fallout from this can be seen by looking at this Carthage bug: https://github.com/Carthage/Carthage/issues/3019

Workarounds (until Carthage itself is updated) include using a wrapper script to exclude the arm64 architecture from simulator builds. But this only fixes the dependencies. The main project must also be updated to EXCLUDE_ARCHS=arm64 for simulator builds, because by default, Xcode will attempt to build for arm64 when doing a simulator build, even though there's no way to run arm64 Simulator on an Intel Mac. Xcode should be smart enough to know this, and not include arm64 in the default build if it's not explicitly excluded. It wastes time and disk space and ultimately fails.

JetForMe on 18 Oct 2020

👍9

Any working solution/build script for Version 12.2 beta 3 (12B5035g)?

EugeneEl on 20 Oct 2020

😕1

I had updated my Xcode to Xcode 12 and could not update my frameworks by Carthage anymore. Thanks for this workaround, now it builds!

therestrictedgirl on 26 Oct 2020

When I remove arm64 architecture from the simulator it works correctly when I compile in the simulator, but it doesn't work on the device and vice versa.
This solution does not work correctly.

bmarcall on 10 Nov 2020

👎1 👍1

When I remove arm64 architecture from the simulator it works correctly when I compile in the simulator, but it doesn't work on the device and vice versa.

This solution does not work correctly.

Well I have apps in App Store with this workaround, I think that you have done something wrong 🤷‍♂️

olejnjak on 10 Nov 2020

👍2

I am hitting a problem with XCode 12.2 when compiling realm:

github "realm/realm-cocoa" "v3.21.0"

It fails like this:

    cd /Users/fmoraes/HSTracker/Carthage/Checkouts/realm-cocoa
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -target arm64-apple-macos10.9 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -L/Users/fmoraes/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/realm-cocoa/v3.21.0/Build/Intermediates.noindex/ArchiveIntermediates/Realm/BuildProductsPath/Release -Lcore -F/Users/fmoraes/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/realm-cocoa/v3.21.0/Build/Intermediates.noindex/ArchiveIntermediates/Realm/BuildProductsPath/Release -filelist /Users/fmoraes/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/realm-cocoa/v3.21.0/Build/Intermediates.noindex/ArchiveIntermediates/Realm/IntermediateBuildFilesPath/Realm.build/Release/Realm.build/Objects-normal/arm64/Realm.LinkFileList -install_name @rpath/Realm.framework/Versions/A/Realm -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath -Xlinker @loader_path/../Frameworks -Xlinker -rpath -Xlinker @executable_path/Frameworks -Xlinker -rpath -Xlinker @loader_path/Frameworks -Xlinker -object_path_lto -Xlinker /Users/fmoraes/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/realm-cocoa/v3.21.0/Build/Intermediates.noindex/ArchiveIntermediates/Realm/IntermediateBuildFilesPath/Realm.build/Release/Realm.build/Objects-normal/arm64/Realm_lto.o -stdlib\=libc++ -fobjc-arc -fobjc-link-runtime -fapplication-extension -lrealm-macosx -lz -compatibility_version 1 -current_version 1 -Xlinker -dependency_info -Xlinker /Users/fmoraes/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/realm-cocoa/v3.21.0/Build/Intermediates.noindex/ArchiveIntermediates/Realm/IntermediateBuildFilesPath/Realm.build/Release/Realm.build/Objects-normal/arm64/Realm_dependency_info.dat -o /Users/fmoraes/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/realm-cocoa/v3.21.0/Build/Intermediates.noindex/ArchiveIntermediates/Realm/IntermediateBuildFilesPath/Realm.build/Release/Realm.build/Objects-normal/arm64/Binary/Realm
ld: warning: ignoring file core/librealm-macosx.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
  "realm::BpTreeBase::replace_root(std::__1::unique_ptr<realm::Array, std::__1::default_delete<realm::Array> >)", referenced from:
      realm::Column<long long>::replace_root_array(std::__1::unique_ptr<realm::Array, std::__1::default_delete<realm::Array> >) in object_store.o
      realm::BpTree<long long>::EraseHandler::replace_root_by_leaf(realm::MemRef) in object_store.o
      realm::BpTree<long long>::EraseHandler::replace_root_by_empty_leaf() in object_store.o
      realm::BpTree<long long>::clear() in object_store.o
      realm::Column<long long>::replace_root_array(std::__1::unique_ptr<realm::Array, std::__1::default_delete<realm::Array> >) in partial_sync.o
      realm::BpTree<long long>::EraseHandler::replace_root_by_leaf(realm::MemRef) in partial_sync.o
      realm::BpTree<long long>::EraseHandler::replace_root_by_empty_leaf() in partial_sync.o
      ...

Any ideas or suggestion to work around it?

fmoraes74 on 13 Nov 2020

@fmoraes74, please file a separate issue.

jdhealy on 13 Nov 2020

@jdhealy Would my problem be similar to https://github.com/Carthage/Carthage/issues/3073 or should I report it separately still?

fmoraes74 on 13 Nov 2020

Any ideas or suggestion to work around it?

@fmoraes74 Update to at least 5.4.8 as there was a fix regarding Carthage compilation, using such outdated releases can always run to issues like this as SDK and IDE evolve quite a lot

olejnjak on 13 Nov 2020

Any ideas or suggestion to work around it?

@fmoraes74 Update to at least 5.4.8 as there was a fix regarding Carthage compilation, using such outdated releases can always run to issues like this as SDK a IDE evolve quite a lot

@olejnjak Thanks for the suggestion. Updating to 5.4.8 does indeed compile now.

fmoraes74 on 13 Nov 2020

When you look at this, I think you've already tried a lot.

I had same case, like this.
so I tried to install two of xcode.

One of Xcode version is 11.7
and One of Xcode version is up to 12.x.

First, I opened my project using xcode 11.7. and then initializing with carthage before build xcode.
(in this step, need to xcode-select command) if you don't have any problem, it will be work.

and then, Once again change to xcode 12 through the xcode-select command.

Finally, resolved your problem.

joonsoo2 on 14 Nov 2020

I had been using Xcode 12 without any issues. They began upon installing Big Sur and Xcode switched to fat binaries in architecture. The workaround suggested only applies to iOS, most of my applications are macOS. I dove into this, because I'm unable to build/ship without this working.

What I've found is that the actual fail (for me) happens during code signing, regardless of application or framework:

A shell task (/usr/bin/xcrun codesign --force --sign - --preserve-metadata=identifier,entitlements /Users/robertomachorro/Library/Developer/Xcode/DerivedData/Moped-dpwskswewweclbdffxexdpiljkcc/Build/Products/Debug/Moped.app/Contents/Frameworks/Highlightr.framework) failed with exit code 1:
/Users/robertomachorro/Library/Developer/Xcode/DerivedData/Moped-dpwskswewweclbdffxexdpiljkcc/Build/Products/Debug/Moped.app/Contents/Frameworks/Highlightr.framework: bundle format is ambiguous (could be app or framework)

Since this happens during the copy framework phase in build (_copy-frameworks_), I experimented taking that out, manually signing the dependencies and then copying manually into the .app - it works!

So, from my perspective, the issue is with the framework copying. Just thought I'd share to see if it helps at your end.

More Info (Edit 1):

The original framework folder will have the following files (within the _Carthage/Build/*_):

lrwxr-xr-x  1 builder  staff   24 Nov 14 14:31 Headers -> Versions/Current/Headers
lrwxr-xr-x  1 builder  staff   27 Nov 14 14:31 PowerLib -> Versions/Current/PowerLib
lrwxr-xr-x  1 builder  staff   24 Nov 14 14:31 Modules -> Versions/Current/Modules
lrwxr-xr-x  1 builder  staff   26 Nov 14 14:31 Resources -> Versions/Current/Resources
drwxr-xr-x  4 builder  staff  128 Nov 14 14:31 Versions

The _carthage copy-frameworks_ command result:

-rwxr-xr-x  1 builder  staff  342176 Nov 15 18:43 PowerLib
lrwxr-xr-x  1 builder  staff      26 Nov 14 14:31 Resources -> Versions/Current/Resources
drwxr-xr-x  4 builder  staff     128 Nov 14 14:31 Versions

Obviously symlinks are missing and the library binary is copied as opposed to being a symlink.

More Info (Edit 2):

As a proof of concept, I commented out the _copy-frameworks_ execution and instead replaced with a straight folder copy and sign:

#/usr/local/bin/carthage copy-frameworks
cp -R $SCRIPT_INPUT_FILE_0 $SCRIPT_OUTPUT_FILE_0
/usr/bin/xcrun codesign --force --sign - --preserve-metadata=identifier,entitlements $SCRIPT_OUTPUT_FILE_0

or more generically:

#/usr/local/bin/carthage copy-frameworks
for ((i=0; i<${SCRIPT_INPUT_FILE_COUNT}; i++)); do
    inname="SCRIPT_INPUT_FILE_$i"
    outname="SCRIPT_OUTPUT_FILE_$i"
    cp -R ${!inname} ${!outname}
    /usr/bin/xcrun codesign --force --sign - --preserve-metadata=identifier,entitlements ${!outname}
done

It works! This is obviously only for testing and to show how a fix can happen.

RobertoMachorro on 15 Nov 2020

Hi there! We used the workaround script (https://github.com/Carthage/Carthage/issues/3019#issuecomment-665136323) with success for a few weeks but now it stopped working. It's because EFFECTIVE_PLATFORM_SUFFIX disappeared.

Here is the updated script that works for us. It uses PLATFORM_NAME instead of EFFECTIVE_PLATFORM_SUFFIX.

#!/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_iphonesimulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8' >> $xcconfig
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(PLATFORM_NAME)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

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

Maybe I'm doing something wrong and EFFECTIVE_PLATFORM_SUFFIX should be there. I'm running Big Sur 11.0.1 and Xcode 12.2.

jcislinsky on 16 Nov 2020

👍6

Any update on when a legitimate fix will become available?

acrabb on 18 Nov 2020

👍9

@acrabb I've been working on one in #3071. It should be ready to go, though it's in need of some testing and review from other maintainers.

elliottwilliams on 18 Nov 2020

👍4 👀2 ❤1

Here’s an update to @jcislinsky’s script above to support tvOS as well as iOS:

#!/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.
for simulator in iphonesimulator appletvsimulator; do
    echo "EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_${simulator}__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8" >> $xcconfig
done
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(PLATFORM_NAME)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

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

pcantrell on 19 Nov 2020

👍7 🎉2

Hi, I am only following certain steps and using someone else's code to build a medical app (using Xcode 12) but I keep getting the build failed error. If I downgrade to Xcode 11, will it work without me having to update the script?

esha1701 on 19 Nov 2020

@esha1701 It should work if you select the correct command line tool.
Screenshot 2020-11-19 at 15 05 26

Gujci on 19 Nov 2020

❤1

Hi, After applying workaround now I'm getting this error " failed to emit precompiled header" tried many things from the internet but nothing happened. is it due to workaround ?

Adnan10858 on 20 Nov 2020

This issue still exist for current latest Homebrew version Carthage (0.35.0)

If Apple use arm64 for simulator as well, can't Carthage use the XCFramework instead ? Which can keep both the same architecture but different platform's binary into a single bundle.

dreampiggy on 23 Nov 2020

❤3

I compiled several comments into a single one (As I think, latest workaround) for an easier understanding of what to do.

Thanks

https://github.com/Carthage/Carthage/issues/3019#issuecomment-665136323
https://github.com/Carthage/Carthage/issues/3019#issuecomment-728021471
https://github.com/Carthage/Carthage/issues/3019#issuecomment-730141782

Workaround

1) Save the script (👇) to your project (e.g. as a carthage.sh file).

Navigate to the root folder of your project
Perform touch carthage.sh in terminal
Open the file you've just created and copy/paste the script provided below to that file.
Save the file 😃

#!/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.
for simulator in iphonesimulator appletvsimulator; do
    echo "EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_${simulator}__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8" >> $xcconfig
done
echo 'EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(PLATFORM_NAME)__NATIVE_ARCH_64_BIT_$(NATIVE_ARCH_64_BIT)__XCODE_$(XCODE_VERSION_MAJOR))' >> $xcconfig

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

2) Make the script executable. Perform chmod +x carthage.sh in terminal
3) Instead of calling carthage ... call ./carthage.sh ...
E.g. ./carthage.sh build or ./carthage.sh update --use-submodules

AndreiMisiukevich on 26 Nov 2020

👍10

Did someone face this issue on the M1? Looks like the script above won't help since arm64 needed in both places: simulator and iPhone. Any ideas how to solve it?

bebecap on 29 Nov 2020

Did someone face this issue on the M1? Looks like the script above won't help since arm64 needed in both places: simulator and iPhone. Any ideas how to solve it?

That's because it won't work on an M1 device. Rather the actual issue being addressed, a poor bandage is being advertised as a solution. Regardless, our project quickly migrated to SPM post binary support releasing and I would recommend others to do the same.

ThePragmaticArt on 29 Nov 2020

👍1

Did someone face this issue on the M1? Looks like the script above won't help since arm64 needed in both places: simulator and iPhone. Any ideas how to solve it?

@bebecap you can try out the amazing work being carried out by @elliottwilliams which doesn't require this workaround

https://github.com/Carthage/Carthage/pull/3071

tmspzz on 29 Nov 2020

❤2

That's because it won't work on an M1 device. Rather the actual issue being addressed, a poor bandage is being advertised as a solution. Regardless, our project quickly migrated to SPM post binary support releasing and I would recommend others to do the same.

As much as SPM is likely to be the future, I really don't like the way I can't check the sources into git. That's what I love about Carthage. I keep a copy of the framework checkouts so I can also rebuild even if there is a GitHub outage or project taken offline.

ddaddy on 29 Nov 2020

Why don’t you checkout the git repo then for the source you want and then add to your workspace? Not quiet sure what your trying to do,

On 29 Nov 2020, at 08:50, Darren Jones notifications@github.com wrote:

That's because it won't work on an M1 device. Rather the actual issue being addressed, a poor bandage is being advertised as a solution. Regardless, our project quickly migrated to SPM post binary support releasing and I would recommend others to do the same.

As much as SPM is likely to be the future, I really don't like the way I can't check the sources into git. That's what I love about Carthage. I keep a copy of the framework checkouts so I can also rebuild even if there is a GitHub outage or project taken offline.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

bukira on 29 Nov 2020

@tmspzz Thanks for the hint. I tried to run carthage update several times with and without cleaning cache.
Of course early problem with lipo is gone.

So now I'm getting
ld: building for iOS Simulator, but linking in dylib built for iOS, file 'Carthage/Build/iOS/Adyen3DS2.framework/Adyen3DS2' for architecture arm64. Based on the log output I've seen some build commands for the x86_64 so the ONLY_ACTIVE_ARCH = NO was changed to ONLY_ACTIVE_ARCH = YES.
Unfortunately it didn't help.

Googling this showed same EXCLUDED_ARCH flag to be used.

P.S. Library is given as an example of the usages in the project. So it's basically first library carthage tries to build
P.S.S. Sorry if some of the questions or the answers are trivial. If you need any extra log output or the step by step description, please let me know.

bebecap on 29 Nov 2020

You can now use SPM with Adyen so you don’t need Carthage

On 29 Nov 2020, at 20:39, Volodymyr Grytsenko notifications@github.com wrote:

@tmspzz Thanks for the hint. I tried to run carthage update several times with and without cleaning cache.
Of course early problem with lipo is gone.

So now I'm getting
ld: building for iOS Simulator, but linking in dylib built for iOS, file 'Carthage/Build/iOS/Adyen3DS2.framework/Adyen3DS2' for architecture arm64. Based on the log output I've seen some build commands for the x86_64 so the ONLY_ACTIVE_ARCH = NO was changed to ONLY_ACTIVE_ARCH = YES.
Unfortunately it didn't help.

Googling this showed same EXCLUDED_ARCH flag to be used.

P.S. Sorry if some of the questions or the answers are trivial. If you need any extra log output or the step by step description, please let me know.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

bukira on 29 Nov 2020

@bukira do you think the problem is in the framework itself but not the carthage?

bebecap on 29 Nov 2020

No that’s not what I am say, but since Xcode 12 and lipo not being suitable anymore the move to SPM seems to be a good move, I love Carthage and the great work done here and is Miles better than cocoapods but since Xcode 12 SPM seems to be the new future so I have embraced it and it seems there has been a big push out there to start supporting it now, with adyen and firebase, Alamofire and rxswift etc and apple have fixed a number or major bugs and a few more to fix with 12.2 so I was suggest moving to spm for adyen rather than fighting with Carthage for it, I’ve used it for our project and seems great so far

On 29 Nov 2020, at 21:15, Volodymyr Grytsenko notifications@github.com wrote:

@bukira do you think the problem is in the framework itself but not the carthage?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

bukira on 29 Nov 2020

👍3

just do clean and try agean

zaidraddad94 on 1 Dec 2020

just do clean and try agean

it's not worked

AnatolyGurbanov on 1 Dec 2020

@bebecap please report the issues you are facing in the PR. Hopefully @elliottwilliams has time to look into those.

tmspzz on 2 Dec 2020

👍1

I'm on a new M1 Mac. Able to use the work-around to build locally for a simulator, but when I try and archive a build (building for a Generic IOS device) I get the same

Environment variable not set: ARCHS

Can anyone direct to me to better information on why the workaround does not work in the above way, and if building on a non-M1 mac will work?

I'm sorry if this is an obvious question, but I'm finding myself a bit over my head with these build issues

EDIT: I resolved my issue. It actually was because I had set an Excluded Architecture (arm64). Once I removed this, and used the workaround script as seen above, the problem resolved.

cody1024d on 3 Dec 2020

@cody1024d for M1 try PR #3071 instead

tmspzz on 3 Dec 2020

@tmspzz Thanks for that, I'll look into it!

cody1024d on 3 Dec 2020

Hi,

I have been trying around, managed to launch the .sh but somehow this still fails :

```haroun@Haroun-MB CFarm % ./carthage.sh update --platform macOS
* Fetching BinanceApi
Fetching Alamofire
Fetching CommonCrypto
Checking out CommonCrypto at "v1.1.0"
Checking out Alamofire at "4.9.1"
Checking out BinanceApi at "1.0.0"
xcodebuild output can be found in /var/folders/_n/snw31djx6ll8zlbfw9db5rt00000gn/T/carthage-xcodebuild.2cNKq5.log
Downloading CommonCrypto.framework binary at "Version 1.1.0"
Building scheme "Alamofire macOS" in Alamofire.xcworkspace
* Building scheme "BinanceApi" in BinanceApi.xcodeproj
Build Failed
Task failed with exit code 65:
/usr/bin/xcrun xcodebuild -project /Users/haroun/Library/Mobile\ Documents/iCloud~com~apple~Playgrounds/Documents/CFarm/Carthage/Checkouts/BinanceApi/BinanceApi.xcodeproj -scheme BinanceApi -configuration Release -derivedDataPath /Users/haroun/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/BinanceApi/1.0.0 ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/_n/snw31djx6ll8zlbfw9db5rt00000gn/T/BinanceApi SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/haroun/Library/Mobile Documents/iCloud~com~apple~Playgrounds/Documents/CFarm/Carthage/Checkouts/BinanceApi)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/_n/snw31djx6ll8zlbfw9db5rt00000gn/T/carthage-xcodebuild.2cNKq5.log
note: Using new build system
note: Building targets in parallel
note: Using codesigning identity override:
note: Planning build
note: Constructing build description
error: The linked framework 'CommonCrypto.framework' is missing one or more architectures required by this target: arm64. (in target 'BinanceApi' from project 'BinanceApi')

* ARCHIVE FAILED *```

It must be something stupid, I guess. I have set everywhere

``
```//:configuration = Debug
EXCLUDED_ARCHS = arm64 arm64e armv7 armv7s armv6 armv8

//:configuration = Release
EXCLUDED_ARCHS = arm64 arm64e armv7 armv7s armv6 armv8

//:completeSettings = some
EXCLUDED_ARCHS
```
I am quite new to all of this, would appreciate some help ! @elliottwilliams as suggested i mention you, don't worry if i take too much time !
Also, would the generated program run under Rosetta2 on a M1 mac ?

superharoun on 6 Dec 2020

@superharoun just to sanity check, are you sure you're invoking the script correctly? The EXCLUDED_ARCH build settings should not be set in Xcode, just in the file exported as XCODE_XCCONFIG_FILE when carthage build is run (that's what the script does). The EXCLUDED_ARCHS lines you pasted above look like they're coming from Xcode, so I thought I'd ask.

elliottwilliams on 7 Dec 2020

Did someone face this issue on the M1? Looks like the script above won't help since arm64 needed in both places: simulator and iPhone. Any ideas how to solve it?

I had the same problem.
Carthage dependencies compiled successfully (using exclude architectures workaround), but when I tried to run project on simulator, I saw this error:
Module 'SomeFrameworkName' was created for incompatible target arm64-apple-ios11.0

You can use workaround for this problem:
Download simulator 13.7 or older. They are using architecture x86_64 and you will be able to proceed.
Yes, it doesn't sounds like a solution, but at least you can run the project in simulator

Vitalii-Gozhenko on 10 Dec 2020

@Vitalii-Gozhenko excluded arch won't work for sure. Since now iOS Simulator as well as Mac architecture is changed to arm64. For M1 you need to try solution from this PR #3071

bebecap on 12 Dec 2020

Since I updated to Xcode 12.3, I've been running into an issue where if any Carthage frameworks are embedded into a framework targets of one of my local projects in my workspace, then I get the following build error for each of those embedded Carthage frameworks:

Building for iOS Simulator, but the linked and embedded framework 'ReSwift.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'ReactiveSwift.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'Apollo.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'iRate.framework' was built for iOS + iOS Simulator.

I built all these dependencies using the official Carthage workaround script. In Xcode 12.2 we did not have any of these errors. I'm not aware of any changes in the Xcode 12.3 patch notes that would indicate there should be a change that would result in this suddenly becoming a problem.

Steps I have taken to try to resolve this:

Don't embed the Carthage dependencies in local frameworks. (This gets rid of the error but seems to have the obvious problematic consequence that now the framework won't be embedded!)
Set the local framework's build setting "build active architectures only" to "no". This does not fix the problem.
Set the local framework's build setting "excluded architectures" to all the ARM architectures: arm64 arm64e armv7 armv7s armv6 armv8 (not just arm64). This did not fix the problem.

Does the Carthage update script need additional changes or what's the deal? Doesn't Xcode know by now that iOS Simulator includes arm64 due to M1 Macs? Why is this still a compiler error? Please advise. Thanks

Note: When building a framework scheme as part of running a playground with "Build Active Scheme" checked, we get a different error that refers to an incompatible architecture "arm64-apple-ios12.0-simulator". Is this nomenclature new to Xcode 12.3?

@elliottwilliams wrote:

@superharoun just to sanity check, are you sure you're invoking the script correctly? The EXCLUDED_ARCH build settings should not be set in Xcode, just in the file exported as XCODE_XCCONFIG_FILE when carthage build is run (that's what the script does). The EXCLUDED_ARCHS lines you pasted above look like they're coming from Xcode, so I thought I'd ask

In the past we found the only way to get our project to build (even after using the above script) was to set "arm64" in the EXCLUDED_ARCH setting within our Xcode project for local framework targets built with ONLY_ACTIVE_ARCH = YES that embed a carthage dependency inside themselves (such as seemed necessary for our Testing configuration to include carthage dependencies like third-party testing frameworks such as OCMock).

Are you saying it shouldn't be necessary to set any excluded architectures?

1oo7 on 14 Dec 2020

👀10 😕1 👍1

Also seeing the new errors on Xcode 12.3 with workaround script:

Building for iOS Simulator, but the linked and embedded framework 'CocoaLumberjackSwift.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'SwiftyJSON.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'SwiftSRP.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'CocoaLumberjack.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the linked and embedded framework 'Alamofire.framework' was built for iOS + iOS Simulator.
Building for iOS Simulator, but the embedded framework 'Buglife.framework' was built for iOS + iOS Simulator.

carlosalban on 15 Dec 2020

👀8

I also experienced the same problem in Xcode 12.3, and I think I found more information.

It seem like Xcode 12.3 does a check up front for any universal binaries for frameworks that are listed in the "Embed Frameworks" build phase.

I found that everything works fine if I setup Carthage in the way described in the README, that is:

Only link the frameworks and not embed them. (The frameworks show up in the "Linked Binary With Libraries" phase but not in the "Embed Frameworks" phase)
And then, embed the frameworks using the carthage copy-framework command in a Run Script build phase.

sandeharsa on 15 Dec 2020

👍10 🚀2

I'm also encountering this issue with Xcode 12.3, but with my test target (not with my app target), for all testing dependencies (for example: Quick, Nimble, etc).

So far as I know, test target dependencies don't use the same configuration as app target dependencies - they are maintained under the "Build Phases" > "Link Binary With Libraries" and utilize a "Copy Files" phase to copy these frameworks to the "Frameworks" destination.

Removing this configuration, as expected, gives the expected Library not loaded: @rpath/Nimble.framework/Nimble error.

Configuring the test target in the same way as the app target by instead using a new Run Script to execute /usr/local/bin/carthage copy-frameworks and adding the test frameworks there (Quick, Nimble, etc) appears to work for me.

I'm not very knowledgable about what Carthage is doing under the hood to know the reason for the original difference in configuring app targets and test targets differently, but the main README says the following (emphasis mine):

In rare cases, you may want to also copy each dependency into the build product (e.g., to embed dependencies within the outer framework, or make sure dependencies are present in a test bundle). To do this, create a new Copy Files build phase with the Frameworks destination, then add the framework reference there as well.

You shouldn't use the carthage copy-frameworks command since test bundles don't need frameworks stripped, and running concurrent instances of copy-frameworks (with parallel builds turn on) is not supported.

Given this, I don't expect that this is a long-term fix, but maybe someone with a better understanding of what's going on here can offer some suggestions..? 🙇🏻‍♂️

derekleerock on 15 Dec 2020

👍4

I'm also encountering this issue with Xcode 12.3, but with my test target (not with my app target), for all testing dependencies (for example: Quick, Nimble, etc).
...
Configuring the test target in the same way as the app target by instead using a new Run Script to execute /usr/local/bin/carthage copy-frameworks and adding the test frameworks there (Quick, Nimble, etc) appears to work for me.

I'm not very knowledgable about what Carthage is doing under the hood to know the reason for the original difference in configuring app targets and test targets differently, but the main README says the following (emphasis mine):

In rare cases, you may want to also copy each dependency into the build product (e.g., to embed dependencies within the outer framework, or make sure dependencies are present in a test bundle). To do this, create a new Copy Files build phase with the Frameworks destination, then add the framework reference there as well.
You shouldn't use the carthage copy-frameworks command since test bundles don't need frameworks stripped, and running concurrent instances of copy-frameworks (with parallel builds turn on) is not supported.

Given this, I don't expect that this is a long-term fix, but maybe someone with a better understanding of what's going on here can offer some suggestions..? 🙇🏻‍♂️

@derekleerock carthage copy-frameworks embeds frameworks into the app being built, but strips inactive architectures from the framework's binary in the process. For example, when building an iOS app to device, copy-frameworks will strip out its simulator image.

There's nothing technically _wrong_ about having a universal framework binary, but it's wasted space in a shipping iOS app. App Store Connect has always enforced that embedded frameworks only contain needed architectures, which is why copy-frameworks has to be run on app targets. Test targets never get shipped, so we've never required usage of copy-frameworks, but it sounds like that may be necessary now that Xcode 12.3 "helpfully" checks for this :)

I don't have 12.3 yet and it's 11pm local time for me, but I'd be interested to know if this new diagnostic emits a warning (and could thus be ignored with SWIFT_TREAT_WARNINGS_AS_ERRORS = NO) and/or if it's controlled by a new build setting.

elliottwilliams on 15 Dec 2020

❤2 👍2 🚀1

@superharoun just to sanity check, are you sure you're invoking the script correctly? The EXCLUDED_ARCH build settings should not be set in Xcode, just in the file exported as XCODE_XCCONFIG_FILE when carthage build is run (that's what the script does). The EXCLUDED_ARCHS lines you pasted above look like they're coming from Xcode, so I thought I'd ask.

Hi @elliottwilliams sorry for the long time without updates have been running around...
I can confirm this was a copy paste from the EXCLUDED_ARCHS from Xcode to show what was there. I also tried without any EXCLUDED_ARCHS with the same negative result.

superharoun on 15 Dec 2020

@derekleerock @elliottwilliams wrote:

@superharoun just to sanity check, are you sure you're invoking the script correctly? The EXCLUDED_ARCH build settings should not be set in Xcode, just in the file exported as XCODE_XCCONFIG_FILE when carthage build is run (that's what the script does). The EXCLUDED_ARCHS lines you pasted above look like they're coming from Xcode, so I thought I'd ask

In the past we found the only way to get our project to build (even after using the above script) was to set "arm64" in the EXCLUDED_ARCH setting within our Xcode project for local framework targets built with ONLY_ACTIVE_ARCH = YES that embed a carthage dependency inside themselves (such as seemed necessary for our Testing configuration to include carthage dependencies like third-party testing frameworks such as OCMock).

I didn't get how to set ONLY_ACTIVE_ARCH = YES on Carthage's side, when i check the log output it is still NO even if I changed it in Xcode.
EDIT : I just added
echo "ONLY_ACTIVE_ARCH = YES" >> $xcconfig
to the .sh script and it seems to have done something.

Would something based on that run on an M1 machine under Rosetta2 ?

Next step is to try downloading the previous simulator version.

superharoun on 15 Dec 2020

Configuring the test target in the same way as the app target by instead using a new Run Script to execute /usr/local/bin/carthage copy-frameworks and adding the test frameworks there (Quick, Nimble, etc) appears to work for me.

Sweet, will try this, thanks!

@elliottwilliams wrote:

I don't have 12.3 yet and it's 11pm local time for me, but I'd be interested to know if this new diagnostic emits a warning (and could thus be ignored with SWIFT_TREAT_WARNINGS_AS_ERRORS = NO) and/or if it's controlled by a new build setting.

We have SWIFT_TREAT_WARNINGS_AS_ERRORS = NO but we still get these build errors. It seems like a regression/bug in Xcode 12.3... this kind of breaking change should not be introduced in a minor Xcode update 👎 .

Note: the first place I encountered this issue is where, in our project, we have an Xcode playground for testing Carthage dependencies. We made a "CarthagePlaygroundSupport" framework that embeds all the Carthage dependencies, as this has been necessary to use binary frameworks built by Carthage in a Playground in past Xcodes. (You also have to set "Build Active Scheme" in your playground and, make sure that your CarthagePlaygroundSupport scheme is active.) Under the hood, playgrounds are containerized apps and it seems they cannot benefit from search paths outside their container, hence why we need to embed Carthage dependencies in them.

The errors we get when building the playground that imports CarthagePlaygroundSupport are of the variety I mentioned above: "Building for iOS Simulator, but the linked and embedded framework 'CocoaLumberjackSwift.framework' was built for iOS + iOS Simulator." (except I have also seen it mention, -target arm64-apple-iosSimulator14.0 or something along those lines—according to my fallible human memory as I didn't keep the logs, and I can't remember the exact combination of settings that gave that result as I was trying lots of different things).

Switching to @elliottwilliams' XCFramework build of Carthage solved all the above issues—playground now works, can embed Carthage dependencies into frameworks again, etc. So I think it's obvious and clear at this point, XCFrameworks is the future and Apple seems to have the writing on the wall...

1oo7 on 15 Dec 2020

Configuring the test target in the same way as the app target by instead using a new Run Script to execute /usr/local/bin/carthage copy-frameworks and adding the test frameworks there (Quick, Nimble, etc) appears to work for me.

Sweet, will try this, thanks!

@elliottwilliams wrote:

I don't have 12.3 yet and it's 11pm local time for me, but I'd be interested to know if this new diagnostic emits a warning (and could thus be ignored with SWIFT_TREAT_WARNINGS_AS_ERRORS = NO) and/or if it's controlled by a new build setting.

We have SWIFT_TREAT_WARNINGS_AS_ERRORS = NO but we still get these build errors. It seems like a regression/bug in Xcode 12.3... this kind of breaking change should not be introduced in a minor Xcode update 👎 .

Note: the first place I encountered this issue is where, in our project, we have an Xcode playground for testing Carthage dependencies. We made a "CarthagePlaygroundSupport" framework that embeds all the Carthage dependencies, as this has been necessary to use binary frameworks built by Carthage in a Playground in past Xcodes. (You also have to set "Build Active Scheme" in your playground and, make sure that your CarthagePlaygroundSupport scheme is active.) Under the hood, playgrounds are containerized apps and it seems they cannot benefit from search paths outside their container, hence why we need to embed Carthage dependencies in them.

The errors we get when building the playground that imports CarthagePlaygroundSupport are of the variety I mentioned above: "Building for iOS Simulator, but the linked and embedded framework 'CocoaLumberjackSwift.framework' was built for iOS + iOS Simulator." (except I have also seen it mention, -target arm64-apple-iosSimulator14.0 or something along those lines—according to my fallible human memory as I didn't keep the logs, and I can't remember the exact combination of settings that gave that result as I was trying lots of different things).

Switching to @elliottwilliams' XCFramework build of Carthage solved all the above issues—playground now works, can embed Carthage dependencies into frameworks again, etc. So I think it's obvious and clear at this point, XCFrameworks is the future and Apple seems to have the writing on the wall...

FYI, the above is an issue with Xcode 12.3 across the border and is not exclusive to Carthage builds. The developer forums have blown up with it.

https://developer.apple.com/forums/thread/669411?answerId=652663022#652663022

ThePragmaticArt on 16 Dec 2020

@1oo7 @ThePragmaticArt out of curiosity, have you tried building with VALIDATE_WORKSPACE = NO? This has been available for bypassing error diagnostics in the past. Obviously not a solution I'd like to rely on but if it works, it'd at least calm things down while we work on xcframework support.

elliottwilliams on 16 Dec 2020

👍2

@1oo7 @ThePragmaticArt out of curiosity, have you tried building with VALIDATE_WORKSPACE = NO? This has been available for bypassing error diagnostics in the past. Obviously not a solution I'd like to rely on but if it works, it'd at least calm things down while we work on xcframework support.

This worked for me as a temporary fix. Note: you can set it to Yes instead of Yes (Error) and it will revert to warnings (instead of build errors).

Screen Shot 2020-12-22 at 6 13 41 PM

terryworona on 23 Dec 2020

👍1

* Building scheme "Masonry iOS" in Masonry.xcworkspace
Build Failed
Task failed with exit code 1:
/usr/bin/xcrun lipo -create /Users/admin/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/Masonry/v1.1.0/Build/Intermediates.noindex/ArchiveIntermediates/Masonry\ iOS/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Masonry.framework/Masonry /Users/admin/Library/Caches/org.carthage.CarthageKit/DerivedData/12.2_12B45b/Masonry/v1.1.0/Build/Products/Release-iphonesimulator/Masonry.framework/Masonry -output /Users/admin/uwb/uwb_ios/uwb_ios/Carthage/Build/iOS/Masonry.framework/Masonry

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

MacOS Catalina , Xcode 12.2 (12B45b)

hebiao6446 on 29 Dec 2020

Considering we're all using a workaround fix for this issue, which is still relevant and active, should this issue really be closed?

It looks like a fix hasn't been release nor even merged onto the main branch yet.

fjcaetano on 4 Jan 2021

👍8

Considering we're all using a workaround fix for this issue, which is still relevant and active, should this issue really be closed?

It looks like a fix hasn't been release nor even merged onto the main branch yet.

@fjcaetano #3071 is merged, which is why we closed this issue. You'll have to start using xcframeworks for your dependencies in order to no longer need the workaround.

elliottwilliams on 4 Jan 2021

🎉4 👍3 ❤1

@elliottwilliams ah, my mistake. I'm using version 0.36 and I thought there wasn't a fix for it yet, but I see that it just hasn't been released yet.

If I may give a suggestion, this thread should be locked while your message is one of the last so users can get a reference to the fix without much hassle.

fjcaetano on 4 Jan 2021

👍4

@elliottwilliams Do you know a projected timeline on publishing the release that will include these changes?

(As an aside, at the time of writing this comment, the README's instructions are misaligned with the latest released version, v0.36, which may lead to some confusion for those trying to integrate.)

Thanks!

eseay on 4 Jan 2021

👍5

@tmspzz please try to release new version with that change.

jesusmateos1234 on 6 Jan 2021

@elliottwilliams Do you know a projected timeline on publishing the release that will include these changes?

(As an aside, at the time of writing this comment, the README's instructions are misaligned with the latest released version, v0.36, which may lead to some confusion for those trying to integrate.)

Thanks!

Good point on the README language – yet another incentive to make progress :)

https://github.com/Carthage/Carthage/issues/3102#issuecomment-755752392

elliottwilliams on 6 Jan 2021

👍1

@elliottwilliams 👋 Thanks for your work in getting xcframework supported for Carthage 👍
Am I correct in saying that prebuilt frameworks do not yet support xcframework?
Thanks

bboyle18 on 7 Jan 2021

@bboyle18 there is no binary support as of yet.

tmspzz on 7 Jan 2021

👍3

Could someone clarify what, if anything, the Carthage 0.36.1 release does regarding this issue? The release notes say XCFrameworks support is not included yet, but that "This is a maintenance release to support integrating frameworks on Xcode 12.3 and above." When I try running carthage bootstrap --platform iOS, I still get the "This usually indicates that project itself failed to compile." error.

Does this mean we still need to use the carthage.sh script that removes Simulator binaries in order to use Carthage 0.36.1 with Xcode 12.3 for now?

ebelinski on 22 Jan 2021

Does this mean we still need to use the carthage.sh script that removes Simulator binaries in order to use Carthage 0.36.1 with Xcode 12.3 for now?

Yes it does.

olejnjak on 22 Jan 2021

👍3

Sorry if that is a stupid question, I'm new to iOS development and Carthage.

Does the workaround script work on Apple M1 machines? Because I'm getting the same error and I'm not sure whether I should change the script and how in order to make it work on Apple M1.

Thx!

akupaka on 26 Jan 2021

👍2

@akupaka I used the script just fine on my M1 MBP. I was not able to use the Simulator though, I could only run the app on a physical device, which I think is the case for Intel Macs as well, but I'm not sure.

ebelinski on 26 Jan 2021

@ebelinski
thanks Eugene.

That is weird. I'm using the up to date macOS and Xcode, installed Brew and Carthage just today, so everything is current version.
And the only framework I'm trying to add is Kingfisher (https://github.com/onevcat/Kingfisher).
I believe I didn't make any mistake in scripts etc...
What could possibly be wrong with my setup?

Script output is

% carthage.sh update --platform iOS                                                   
*** Fetching Kingfisher
*** Checking out Kingfisher at "6.0.1"
*** xcodebuild output can be found in /var/folders/53/g2mcdvvn2z74nslhv21n0qx00000gn/T/carthage-xcodebuild.7gVRUR.log
*** Downloading Kingfisher.framework binary at "6.0.1 - Bind & Hug"
*** Building scheme "Kingfisher" in Kingfisher.xcworkspace
Build Failed
    Task failed with exit code 1:
    /usr/bin/xcrun lipo -create /Users/user/Library/Caches/org.carthage.CarthageKit/DerivedData/12.3_12C33/Kingfisher/6.0.1/Build/Intermediates.noindex/ArchiveIntermediates/Kingfisher/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Kingfisher.framework/Kingfisher /Users/user/Library/Caches/org.carthage.CarthageKit/DerivedData/12.3_12C33/Kingfisher/6.0.1/Build/Products/Release-iphonesimulator/Kingfisher.framework/Kingfisher -output /Users/user/Documents/study/ios/ios2020fs/MovieInfo5-1/Carthage/Build/iOS/Kingfisher.framework/Kingfisher

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

Log says * BUILD SUCCEEDED * in the end.

akupaka on 26 Jan 2021

im getting the same issue as @akupaka. happens on the very first building scheme attempt. im new to carthage and recently got the M1 MBP. the script works perfectly fine for my 6 year old MBP, all with same carthage versions and xcode version.

xcode: 12.3
carthage: 0.36.1

different variations of call script used:
carthage.sh bootstrap --platform iOS --no-use-binaries
carthage.sh bootstrap --platform iOS --cache-builds

Building scheme "Atributika-iOS" in Atributika.xcodeproj
Build Failed
    Task failed with exit code 1:
    /usr/bin/xcrun lipo -create /Users/dawid/Library/Caches/org.carthage.CarthageKit/DerivedData/12.3_12C33/Atributika/4.9.10/Build/Intermediates.noindex/ArchiveIntermediates/Atributika-iOS/IntermediateBuildFilesPath/UninstalledProducts/iphoneos/Atributika.framework/Atributika /Users/.../Library/Caches/org.carthage.CarthageKit/DerivedData/12.3_12C33/Atributika/4.9.10/Build/Products/Release-iphonesimulator/Atributika.framework/Atributika -output /Users/.../Carthage/Build/iOS/Atributika.framework/Atributika

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/23/c0v1r6jn71j7gx82xpflxw5w0000gn/T/carthage-xcodebuild.4PZCh4.log

skibadawid on 26 Jan 2021

Has the same issue as @akupaka on M1 mac with Alamofire

kruperfone on 27 Jan 2021

👍2

small update on my end, got the schemes to build properly. if you're using M1 mac, make sure the Terminal or iTerm youre using is opened using Rosetta. that was the key difference that made it to work. and to do that; quit your terminal, right click on it, select 'get info', and then check the checkbox with 'Open using Rosetta'. Tho cant run the app in simulator.
@akupaka @kruperfone

skibadawid on 27 Jan 2021

👍6

@skibadawid it works, thanks!

kruperfone on 28 Jan 2021

I have totally ditched Carthage and cocoapods and gone full swift package manager and Xcode 12.x
Not that I didn’t/don’t like Carthage, it’s amazing what’s been made but SPM is the future and even devs who make Carthage agree.
I strongly recommend it

On 28 Jan 2021, at 07:13, Sergey Nikolaev notifications@github.com wrote:

@skibadawid it works, thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

bukira on 28 Jan 2021

👍2 👀1

Hi there,

We have been using the cathrage.sh since Xcode 12 and it seems working great, but suddenly the tvOS failed starting in this month, but we changed nothing about the process.

And furthermore, iOS and macOS CI passed at the same time, with same code and setup. It's really confusing for us how to fix it.

The error:

Processing Info.plist
▸ Running script 'Copy Carthage Frameworks'
❌  error: /Applications/Xcode-12.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: one of -create, -thin <arch_type>, -extract <arch_type>, -remove <arch_type>, -replace <arch_type> <file_name>, -verify_arch <arch_type> ... , -archs, -info, or -detailed_info must be specified
Testing failed:
    /Applications/Xcode-12.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: one of -create, -thin <arch_type>, -extract <arch_type>, -remove <arch_type>, -replace <arch_type> <file_name>, -verify_arch <arch_type> ... , -archs, -info, or -detailed_info must be specified
    Testing cancelled because the build failed.
** TEST FAILED **
The following build commands failed:
    PhaseScriptExecution Copy\ Carthage\ Frameworks /Users/travis/Library/Developer/Xcode/DerivedData/ChartsDemo-iOS-aeselevbqicktffmzvanvfzicpzm/Build/Intermediates.noindex/Charts.build/Debug-appletvsimulator/ChartsTests.build/Script-6BA68666BDA3FCF79C2A6801.sh
(1 failure)
rake aborted!

iOS passed: https://travis-ci.org/github/danielgindi/Charts/jobs/756550942
tvOS constantly fail: https://travis-ci.org/github/danielgindi/Charts/jobs/756550943

Our carthage script: https://github.com/danielgindi/Charts/blob/master/carthage.sh

the script we use: https://github.com/danielgindi/Charts/blob/master/.travis.yml

Could anyone shed some lights?

liuxuan30 on 29 Jan 2021

@liuxuan30, thanks for filing a separate issue for that. The info we request in the ⧼New Issue Template⧽ might be helpful in solving this.

jdhealy on 29 Jan 2021

yeah sorry about the duplicate. I think new issue would be better since this is closed. We are also open source so you can grab everything you need.

liuxuan30 on 29 Jan 2021

@skibadawid ,
I was able to run it using arch -x86_64 carthage.sh update Kingfisher --platform iOS after your suggestion. Thx!
Although it does not start in iOS simulator.

akupaka on 30 Jan 2021

👍1

BTW, are there any plans to support xcframeworks?

sudeepdino008 on 8 Feb 2021

BTW, are there any plans to support xcframeworks?

https://github.com/Carthage/Carthage/releases/tag/0.37.0

olejnjak on 8 Feb 2021

@sudeepdino008 newest 0.37.0 supports xcframeworks

matopeto on 8 Feb 2021

@olejnjak @matopeto Does that mean we don't have to use the workaround?

sudeepdino008 on 8 Feb 2021

Yes, it is not needed anymore, but read documentation about migration.

matopeto on 8 Feb 2021

It is the first line in release notes

Building a framework using Xcode 12 fails with a build error from xcrun lipo (#3019). Fix by passing --use-xcframeworks and re-integrating your dependencies as XCFrameworks, or by using a workaround xcconfig on Intel-based Macs.

olejnjak on 8 Feb 2021

👍1

The XCFramework need adoptation. And all framework author has to change each of their SDK, including the downstream dependency.

For example, SDWebImage, has more than 20 individual SDKs. Which means, I have to release 20+ versions to XCFramework transition. Which is a really big job. Especially for many large project, like FirebaseSDK as well.

Why not carthage provide one easy way, to edit Xcode's xcproj file when user run carthage update --use-xcframework, automatically help SDK authors to change the Foobar.framework dependency into Foobar.xcframework depdendency then build. (The reademe shows this can been done by manual steps, so why can't been done automatically ?) Isn't this is a much more easier solution ? Everyone don't need adoptation.

Compared to CocoaPods, which can have plugins to switch between static framework/dynamic framework/xcframework any package type, without the SDK authors's any changes. Which is much more easier to use. But Carthage make this package type switch need many manual steps and SDK version bump. I think package type (Whether one SDK use XCFramework or normal framework) should not provide a different version. They're just the format we use.

Is this because of Swift's limit that can not handle Xcode xcproj's file format ?

dreampiggy on 23 Feb 2021

On Feb 23, 2021, at 02:50, DreamPiggy notifications@github.com wrote:

Why not carthage provide one easy way, to edit Xcode's xcproj file, automatically help SDK authors to change the Foobar.framework dependency into Foobar.xcframework depdendency ? Isn't this is a much more easier solution ?

It’s easy to describe, but would be
nontrivial to implement correctly in all cases, and goes against Carthage’s goal of simplicity. We have hard rule against Carthage ever messing with the xcodeproj directly.

From https://github.com/Carthage/Carthage#differences-between-carthage-and-cocoapods:

CocoaPods (by default) automatically creates and updates an Xcode workspace for your application and all dependencies. Carthage builds framework binaries using xcodebuild, but leaves the responsibility of integrating them up to the user. CocoaPods’ approach is easier to use, while Carthage’s is flexible and unintrusive.
[…]
we created Carthage because we wanted the simplest tool possible—a dependency manager that gets the job done without taking over the responsibility of Xcode, and without creating extra work for framework authors. CocoaPods offers many amazing features that Carthage will never have, at the expense of additional complexity.

If you want to build something like this yourself, go for it (https://github.com/tuist/XcodeProj is a great library), but I don’t think Carthage would ever want to do this.

elliottwilliams on 24 Feb 2021

😕1 👍1

On Feb 23, 2021, at 02:50, DreamPiggy @.*> wrote: Why not carthage provide one easy way, to edit Xcode's xcproj file, automatically help SDK authors to change the Foobar.framework dependency into Foobar.xcframework depdendency ? Isn't this is a much more easier solution ?
It’s easy to describe, but would be nontrivial to implement correctly in all cases, and goes against Carthage’s goal of simplicity. We have hard rule against Carthage ever messing with the xcodeproj directly. From https://github.com/Carthage/Carthage#differences-between-carthage-and-cocoapods:

I understand what you says but leaves the responsibility of integrating them up to the user. But remember, Who is user Carthage desired to service and Which Xcode Project is messing.

In my opinion, there are two types of people during SDK distribution:

User: SDK consumer, who is responsible to integrate SDK into App Project. Carthage should not touch App Project, right ?
SDK Author: SDK creater, who is responsible to create SDK and config for Carthage compatible. Carthage should provide help and conveniences for them to distrubte their SDKs.

For Xcode Project, all the things I talked above, don't need to modify App Project. It just need to modify the Carthage/Checkout temp directory and temp Xcode project. User don't need to care about it (It does not change your App Project), which only help SDK Author to change it temporary when use. Then it will be reset.

Solution

If I redesign Carthage about how to change the SDK's distribution type (including framework/xcframework package type, or static/dynamic linkage), I will provide these follow command combination:

carthage build: All Carthage/Checkout Xcode Project will change the Package Type into framework. Don't change Linkage Type at all.
carthage build --use-xcframework: All Carthage/Checkout Xcode Project will change the Package Type into xcframework. Don't change Linkage Type at all.
carthage build --static: All Carthage/Checkout Xcode Project will change the Package Type into framwork, and MACH_O_TYPE configuration into staticlib.
carthage build --dynamic: All Carthage/Checkout Xcode Project will change the Package Type into framwork, and MACH_O_TYPE configuration into mh_dylib.
carthage build --use-xcframework --static: All Carthage/Checkout Xcode Project will change the Package Type into xcframwork, and MACH_O_TYPE configuration into staticlib.
carthage build --use-xcframwork --dynamic: All Carthage/Checkout Xcode Project will change the Package Type into xcframwork, and MACH_O_TYPE configuration into mh_dylib.

So, the modification is happened during carthage build command. When build finished (whether success or failed, don't care). All the changes to Xcode Project will be reset to its original status (use git reset is enough).

User can pick the final product (framework or xcframework) to integrate to App Project. User don't need to realize the changes during the building.

Under this solution, let's see what benefit to these two people:

User: I can easily switch and build between Package Type and Linkage Type. I still need to integrate by myself to the App Project. But I don't need to wait for all the SDKs I used to release new versions for current situation.
SDK Author: I can just create only one Xcode Target for distribution, Carthage take care the Package Type/ Linkage switching. But I don't need hacking to creating 4 targets for current situation (dynamic or static, framework or xcframework, 2x2=4 combinations)

For binary distribution, Carthage can check whether the Package Type and Linkage matches, if not, report error to User or SDK author.

dreampiggy on 24 Feb 2021

@dreampiggy that's an interesting idea! You could actually build a CLI that works like you're describing _on top_ of carthage, by creating an xcconfig file and using the XCODE_XCCONFIG_FILE environment variable. You could set up a Makefile to run carthage this way, and then you'd be able to do things like force all your frameworks to build as staticlibs.

Carthage doesn't natively override project build settings, except for a few cases where it's necessary to get semantics right (examples include ONLY_ACTIVE_ARCH=YES and the FRAMEWORK_SEARCH_PATHS override introduced in 0.37.0). This is intentional. Carthage is trying to be simple and make dependencies build as similarly to their source repo as possible, giving framework authors control over how their framework builds and is distributed.

I politely want to mention that we're super out of scope of this issue :) If you'd like to discuss further, please open a new issue.

elliottwilliams on 26 Feb 2021

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

Most helpful comment

Workaround that works with both Xcode 11 and 12

How to use

Script

All 270 comments

Workaround that works with both Xcode 11 and 12

How to use

Script

carthage-build.sh

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

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:

Xcode 12 beta 4

Xcode 12 beta 5

Xcode 12 beta 6

carthage-build.sh

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

For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise

the build will fail on lipo due to duplicate architectures.

Workaround

Solution

Related issues