Carthage build/update/bootstrap don't work in an Xcode run script build phase

[pepeInvasion]

• carthage install method: [ ] .pkg, [X] homebrew, [ ] source
• which carthage: /usr/local/bin/carthage
• carthage version: 0.31.1
• xcodebuild -version: Xcode 10.0; Build version 10A255
• Are you using --no-build? No
• Are you using --no-use-binaries? No
• Are you using --use-submodules? No
• Are you using --cache-builds? Yes (but with NO is the same)
• Are you using --new-resolver? No

Building dependencies with carthage build script in XCode 10 produce

Task failed with exit code 65:

Carthage Output

<unknown>:0: error: unable to load standard library for target 'arm64-apple-ios9.0-simulator'

** ARCHIVE FAILED **


The following build commands failed:
    CompileSwift normal armv7
    CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
    CompileSwift normal arm64
(3 failures)

Actual outcome
XCode build failed, but only for ios-simulator. When I build app for physical device or generic, carthage build step pass through without any errors. On XCode 9 everything is ok.

Expected outcome
Carthage script should build dependencies for app on ios simulator on XCode 10.

[tmspzz]

I think this is a problem with your setup.

_{Sent with GitHawk}

[pepeInvasion]

Hmmm... but maybe you @blender or anybody else can point me, what should I check, because I tried a dozen of different setup combinations and nothing works...

[mdiep]

Look in the xcode build log (Carthage prints that path), find the xcodebuild invocation its using, and try running that separately.

[pepeInvasion]

@mdiep running xcodebuild command separately in terminal works fine. Only running from XCode 10 build script fail.

[demosten]

Me and a colleague of mine are having the same issue while other 8 colleagues does not. It might be related to different env variables Xcode10 provides. Carthage builds fine from console but not from Xcode10 for me. I've compared the Xcode9 and 10 env variables and found the following:

Xcode9 => CURRENT_ARCH=x86_64,arch=x86_64
Xcode10 => CURRENT_ARCH=undefined_arch,arch=undefined_arch

So temporary worked around the problem by doing: env -i CURRENT_ARCH=x86_64 arch=x86_64 my_carthage_script.sh in Xcode10 script phase. It might not be a carthage problem though.

[ikesyo]

Looks like this is related to https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes/build_system_release_notes_for_xcode_10

The new build system passes undefined_arch as the value for the ARCH environment variable when running shell script build phases. The value was previously not well defined. Any shell scripts depending on this value must behave correctly for all defined architectures being built, available via the ARCHS environment variable.

and https://github.com/Carthage/Carthage/issues/992#issuecomment-172977120.

[nicolas-miari]

The new build system passes undefined_arch as the value for the ARCH environment variable when running shell script build phases. The value was previously not well defined. Any shell scripts depending on this value must behave correctly for all defined architectures being built, available via the ARCHS environment variable.

I'm curious as to what type of shell script @pepeInvasion is running in order to run into this problem. I think I only have the standard /usr/local/bin/carthage copy-frameworks and perhaps "Run Swiftlint"...
I guess I'll be OK for the time being...

[ikesyo]

@nicolas-miari Using carthage copy-frameworks will not be affected. This issue is referring to running build/update/bootstrap commands (so using xcodebuild command) in script build phases.

[davidpasztor]

I'm running into the same issue when trying to run a ksh script like this:
env -i CURRENT_ARCH=x86_64 arch=x86_64 "$SRCROOT"/../my_script.sh, however this also resets the stored SSH credentials, which are needed for fetching a non-public carthage framework. Does anyone have a workaround for that?

It seems that if I don't reset my environment, just set those two variables using env CURRENT_ARCH=x86_64 arch=x86_64 "$SRCROOT"/../my_script.sh, I can connect to the git server, but I still receive the error

<unknown>:0: error: unable to load standard library for target 'arm64-apple-ios8.0-simulator'

and carthage update fails.

Also, by calling env inside my_script.sh and piping its output to a file, I can see that bothCURRENT_ARCH and arch are indeed undefined_arch by default, but by invoking the script like env CURRENT_ARCH=x86_64 arch=x86_64 "$SRCROOT"/../my_script.sh, both are set correctly. However, I still receive the carthage update error.

Update: realised that the actual part that fails is the xcodebuild command that's being run after all checkout succeeds. Manually running carthage checkout and then

/usr/bin/xcrun xcodebuild -workspace .../Alamofire.xcworkspace -scheme Alamofire\ iOS -configuration Release -derivedDataPath .../DerivedData/10.0_10A255/igalamofire/4.7.3 -sdk iphonesimulator12.0 ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES build SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO

instead of running

/usr/bin/xcrun xcodebuild -workspace .../Alamofire.xcworkspace -scheme Alamofire\ iOS -configuration Release -derivedDataPath .../DerivedData/10.0_10A255/igalamofire/4.7.3 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath .../igalamofire SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO

succeeds (the important difference is the use of -sdk iphonesimulator12.0 instead of -sdk iphoneos,but this cannot be run with archive, hence the change to build as well) . However, this only builds, doesn't archive.

[borisyurkevich]

I'm experiencing same problem, trying my luck on Stack Overflow.

[davidpasztor]

@MojtabaHs sadly that still doesn't solve the issue.

My current workaround is calling carthage update --platform iOS --no-build and then calling xcodebuild ${PLATFORM_NAME} build for all dependencies, but this is quite a pain, since I have to find all dependencies in the Checkouts folder and make sure that I pass the correct arguments to xcodebuild dynamically, so an update or at least acknowledgement of the issue/answer from the Carthage team would be much appreciated

[drkibitz]

This is happening to me too, and unfortunately workarounds are not great. I was hoping to get some people into using Carthage by showing how easy it is 🤷‍♂️. Hopefully I can find something that doesn't require any manual steps.

[drkibitz]

Found a decent work around I think, here's my full Run Script Phase:

## env -i is a work around for https://github.com/Carthage/Carthage/issues/2613
CARTHAGE=$(command -v carthage)
env -i $CARTHAGE build --project-directory "${SRCROOT}" --platform "${PLATFORM_NAME}"

Seems just running in a clean environment avoids picking up the xcode environment things carthage introspects.

[davidpasztor]

@drkibitz sadly that's not a solution for anyone whose build script relies on other environment variables that are not coming directly from Xcode, i.e. SSH keys for accessing the git-server from which internal libraries are downloaded, since env -i resets all environment variables.

[drkibitz]

@davidpasztor unless you have subdependencies running Carthage commands, which you shouldn’t anyway, this is just the build command. You can ensure your dependencies are up to date in the current shell, with fetch or update —no-build. Then do this for only building. This is exactly what I’m doing.

[drkibitz]

My work around seems to be having a weird hard to track issue. Or maybe more than one.
After an initial clone to a new computer, my project fails to build using my previously mentioned work around. If I delete this directory:

rm -rf ~/Library/Caches/org.carthage.CarthageKit/DerivedData

It works, and works after cloning a second time and clearing all my caches.

I'm not sure what the problem is, or how Carthage might be caching something incorrectly as the build does not give any useful info other than the build command of one of my dependencies exiting with code 72. There are also no notes to open another log file elsewhere. I'm also passing --verbose, still no useful info.

I'm about to just add the rm to my runscript as an addition to the workaround, but wondering if any of this sounds familiar.

[stale[bot]]

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

[drkibitz]

Please don't close this issue.

[stale[bot]]

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

[davidpasztor]

Please don’t close this issue as it still hasn’t been fixed by the Carthage team after several months :(

[tmspzz]

@davidpasztor you seem eager to help, do you want to give it a shot?

[drkibitz]

@davidpasztor @blender my workaround is no longer needed if I run carthage with xcrun, e.g. xcrun carthage .... Not sure if that's still a workaround, if so, it's a better one than the env -i.

[drkibitz]

I also have no idea why running via xcrun seems to fix this, along with a weird rm -rf exit 72 issue.

[asgoth]

@drkibitz Cool, will try the xcrun trick as env -i worked on High Sierra, but failed on Mojave with a rm -rf exit 72 issue.

[davidpasztor]

@drkibitz I modified my pre-build script to call Carthage like xcrun carthage update --platform iOS 2>&1, but I still get the aforementioned issue

[davidpasztor]

I think this is a problem with your setup.

Sent with GitHawk

@blender Just did some further testing and I can reproduce the issue even from a brand new project by simply calling carthage update --platform iOS in the pre-build run script phase of the project. So the issue has nothing to do with the project setup, it occurs every time carthage update calls xcodebuild from a pre-build run script phase.

@davidpasztor you seem eager to help, do you want to give it a shot?

It would be much easier for one of the active contributors of the project to fix the issue considering they're already familiar with the code base, but if worst comes worst, I might have to give it a shot.

[davidpasztor]

The issue seems to be caused by the environment variable LLVM_TARGET_TRIPLE_SUFFIX. Unsetting that in the pre-build script before calling carthage update solves the issue.

unset LLVM_TARGET_TRIPLE_SUFFIX
carthage update 2>&1

[baligit]

The issue seems to be caused by the environment variable LLVM_TARGET_TRIPLE_SUFFIX. Unsetting that in the pre-build script before calling carthage update solves the issue.

unset LLVM_TARGET_TRIPLE_SUFFIX
carthage update 2>&1

I run on the terminal the following command :
$unset LLVM_TARGET_TRIPLE_SUFFIX
carthage update 2>&1

$/Scripts/bootstrap.sh -d

Fetching dependencies
Dependencies up-to-date

but it does not work unfortunately! any help?