Fix 'objdump' call not working with Xcode 13.3 command line tools

[mikchmie]

Fixes #3253

[tmspzz]

@mikchmie thanks! Will this still work with previous versions of Xcode or macOS?

[mikchmie]

I'm checking it right now. So far I've checked options' syntax in following versions of `objdump:

• Apple LLVM version 13.1.6 (clang-1316.0.19.2) - Xcode 13.3
• Apple LLVM version 13.0.0 (clang-1300.0.29.30) - Xcode 13.2.1
• Apple LLVM version 12.0.5 (clang-1205.0.22.9) - Command_Line_Tools_macOS_10.12_for_Xcode_8.3.2

and it looks the same (with two dashes --).

@tmspzz What is the minimum version of Xcode that Carthage supports?

[mikchmie]

~~Looks like the syntax was changed in LLVM 10 in 2019.~~

~~Last LLVM 9 docs capture:~~ ~~https://web.archive.org/web/20190616123225/http://www.llvm.org:80/docs/CommandGuide/llvm-objdump.html~~ ~~First LLVM 10 docs capture:~~ ~~https://web.archive.org/web/20190812120449/http://llvm.org:80/docs/CommandGuide/llvm-objdump.html~~

[mikchmie]

I've also found LLVM's historic documentation and looks like the change actually happened in LLVM 9 (released 19 Sep 2019). I suppose this is a more reliable way to pinpoint the moment of change, than the WaybackMachnie.

LLVM 8.0.1 docs (-macho): https://releases.llvm.org/8.0.1/docs/CommandGuide/llvm-objdump.html

LLVM 9.0.0 docs (--macho): https://releases.llvm.org/9.0.0/docs/CommandGuide/llvm-objdump.html

According to Wikipedia it means that this new syntax would work in Xcode 11.4+.

[mikchmie]

@tmspzz If that's necessary I can add a fallback to the chain, e.g.:

return task.launch(standardInput: nil)
    .flatMapError { _ -> SignalProducer<TaskEvent<Data>, TaskError> in
        // Fallback for 'objdump' in LLVM <9.0.0 (Xcode <11.4) which uses `-` as option prefix instead of `--`
        Task("/usr/bin/xcrun", arguments: [
            "objdump",
            "-macho",
            "-private-header",
            "-non-verbose",
            url.resolvingSymlinksInPath().path,
            ]
        ).launch(standardInput: nil)
    }

[krzyzanowskim]

I tried this patch with Xcode 13.2.1 and binary xcframework didn't land in ./Carthage/Build/<Platform>/ as per #3253

[mikchmie]

@krzyzanowskim As far as I can tell XCFrameworks (*.xcframework) will never land in ./Carthage/Build/<Platform>/ - instead they should be placed in ./Carthage/Build/ - as they usually contain binaries for multiple platforms. Only "basic" frameworks (*.framework) land in ./Carthage/Build/<Platform>/.

[krzyzanowskim]

@mikchmie you're right. I just noticed I face a different issue, where the Xcode project that supposes to use .xcframework, links to a non-existing framework from ./Carthage/Build/<Platform>/

[mikchmie]

@tmspzz Are there any plans to fix the issue mentioned in this PR (either by merging my PR or some other way)? Xcode 13.3 Release Candidate has already been released, so it won't be long before it's fully released to the public and will give Carthage users trouble.

[daumantas-versockas-vinted]

@tmspzz since Xcode 13.3 is released, we are having trouble with it. Are you planning to resolve this issue in the nearest future?

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

[mikchmie]

Is the project itself "stale"? Are there any active maintainers who could make Carthage compatible with latest Xcode versions?

[CraigSiemens]

We're also waiting for this fix.

• https://github.com/Carthage/Carthage/issues/3269

[vilu]

Same! Would be happy to help support this.

[CraigSiemens]

Our current workaround is to copy over the frameworks ourself. We've already got a script running Carthage so we added this at the end.

# carthage build ...

mkdir -p Carthage/Build/iOS
destination=$(mktemp -d)
tar_path=$(find "$HOME/Library/Caches/org.carthage.CarthageKit/binaries/GoogleMaps" -iname "GoogleMaps*.gz")
tar -xf "$tar_path" -C "$destination"
find "$destination" -d -iname "*.framework" -exec cp -R {} Carthage/Build/iOS \;
rm -r "$destination"

[Ro-M]

@tmspzz could you please provide feedback here? Is there anything that you would like us to add / change / explain in order to move this forward?

To summarise The earliest LLVM version Carthage relies on for this particular command requires LLVM 3.8.0 which is already supporting the usage of the double-dash prefix.

In more detail

• objdump is not accepting single-dash prefixed parameters starting with LLVM 13.1.6 which is bundled with the Command Line Tools of Xcode 13.3
• The new syntax for objdump requires a double-dash prefix for parameters
• This causes Carthage to fail silently when trying to check out binary dependencies
• The new syntax is already supported since LLVM 3.8.0 bundled with Xcode 7.2.1
• LLVM 3.7.0 does not have the -private-header option which is needed here, so LLVM 3.8.0 is the earliest version that this step has to support

[mikchmie]

@Ro-M Thanks for the summary 👍 Just 2 tiny corrections:

• objdump is not accepting single-dash prefixed parameters starting with LLVM 13.1.6 which is bundled with the Command Line Tools of Xcode 13.3

For the sake of clarity let's stick to one versioning system (the one described as LLVM in table on Wikipedia). 13.1.6 comes from the Clang version string which Apple's builds print as their version. The official LLVM version is 13.0.0.

• The new syntax is already supported since LLVM 3.8.0 bundled with Xcode 7.2.1

Actually it's bundled since Xcode 7.3. Xcode 7.2.1 used LLVM 3.7.0

[irmakcan]

This change fixes my issue on Xcode 13.4 as well. Hope it gets merged and released soon.

[mneuwert]

Hey dudes, did carthage bite the dust? Is somebody planning to merge it? Not usable anymore with Xcode 13.3 - 14. May be also just call otool -h as higher level abstraction?

[Ro-M]

@mneuwert I'm not sure about the current plans from the maintainers. As for this PR I would like to move this forward but need direction as to what's missing here. We currently are using a fork of carthage that also includes this change. For the future we are looking into carthage alternatives that have a more active support 😞

[mikchmie]

@giginet Could you review this PR?