BartyCrouch: Cocoapods executable doesn't work on x86 machines

Expected Behavior

Running the executable distributed via cocoopods in a build phase works as expected. Example: ${PODS_ROOT}/BartyCrouch/bartycrouch lint -x --fail-on-warnings

Actual Behavior

An error is returned: bartycrouch: Bad CPU type in executable

Steps to Reproduce the Problem

  1. Run the executable found at Pods/BartyCrouch/bartycrouch

Specifications

  • Version: 4.9.0
  • Platform: iOS
  • IDE Version: Xcode 13.2.1

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 19 (15 by maintainers)

Most upvoted comments

As @Hilehele mentioned, it’s looking for the dylib one level too high: in the Pods folder instead of in the Pods/BartyCrouch folder. A tweak of the rpath should fix this, the current rpaths are:

  • /usr/lib/swift
  • @executable_path/…/lib

We should add @executable_path to that list. Tried it locally with this line, and Bartycrouch now works:

install_name_tool -add_rpath @executable_path/. Pods/BartyCrouch/bartycrouch

Until BartyCrouch switches to SwiftParser, we’ll need to adapt the Makefile, particularly the portable_zip section (as it’s used for the Cocoapods release). I’d recommend creating a temporary folder, copying all the artifacts in there, tweaking the rpath, and then zipping the whole thing.

portable_zip: bartycrouch_universal
	rm -f "$(BUILDDIR)/Apple/Products/Release/portable_bartycrouch.zip"
	
	$(eval TMP := $(shell mktemp -d))
	cp "$(BUILDDIR)/Apple/Products/Release/bartycrouch" "$(TMP)/bartycrouch"
	@install_name_tool -add_rpath "@executable_path/." "$(TMP)/bartycrouch"
	
	zip -j "$(BUILDDIR)/Apple/Products/Release/portable_bartycrouch.zip" \
		"$(TMP)/bartycrouch" \
		"$(REPODIR)/LICENSE" \
		".build/artifacts/swift-syntax/_InternalSwiftSyntaxParser.xcframework/macos-arm64_x86_64/lib_InternalSwiftSyntaxParser.dylib"
	echo "Portable ZIP created at: $(BUILDDIR)/Apple/Products/Release/portable_bartycrouch.zip"
	rm -rf $(TMP)

Note: I’m a noob at makefiles. If there’s a better way to temporarily create a folder and tweak the binary, go ahead. Note @Hilehele: you don’t need to create folders and move files, just use the install_name_tool command above to fix your executable until is permanently fixed.

@djbe Thank you very much for the fix! I merged it and made a new release (4.14.2), please report if there’s still an issue!

Yeah can confirm that it’s not working yet, just tried it.

Had a look through the SwiftLint PR, the code changes seem very minimal (if you ignore some other unrelated changes in that PR). Sourcery also switched to it a few months ago (PR).

Regarding installation methods, for SPM there should be no change, as long as your package.swift works. Homebrew should just create a release build via SPM. Or via your makefile 🤷 For SwiftGen, our brewfile invokes our rake build, which in turn just calls swift build --disable-sandbox -c release. Non brew builds trigger a universal build with --arch arm64 --arch x86_64.

I’ve put up an edit to the Makefile which should solve the issue. #246