search

beeware / briefcase

Tools to support converting a Python project into a standalone native application.
https://briefcase.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
2.48k stars 352 forks source link

Cannot code sign on Big Sur MacOS #1818

Open JonathanLoungani opened 1 month ago

JonathanLoungani commented 1 month ago

Describe the bug

When following the BeeWare tutorial on a Big Sur MacOS (x86_64), the briefcase build command is unable to code sign.

Steps to reproduce

  1. Follow the steps in the BeeWare tutorial until Tutorial 3 – Packaging for distribution.
  2. Run briefcase create
  3. Run briefcase build
  4. Observe that the briefcase build command fails with the following error: 
    Unable to code sign /Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app.

    Notably, the command

    codesign '/Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app' --sign - --force --entitlements /Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Entitlements.plist

Produces the following result:

/Library/Developer/CommandLineTools/usr/bin/codesign_allocate: fatal error: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): /Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app/Contents/MacOS/Hello World (for architecture x86_64)
/Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app: the codesign_allocate helper tool cannot be found or used

Expected behavior

The ad-hoc signing should complete without issue.

Screenshots

No response

Environment

Logs

briefcase.2024_05_20-16_37_34.build.log

Additional context

No response

JonathanLoungani commented 1 month ago

I am looking further into this issue. Currently, this StackOverflow post suggests that "This problem happens when xcode-select developer directory was pointing to /Library/Developer/CommandLineTools when a full regular Xcode was required (happens when CommandLineTools are installed after Xcode)".

I verified that xcode-select -p prints /Library/Developer/CommandLineTools. In addition, the following is output after entering the command xcodebuild

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
freakboy3742 commented 1 month ago

Interesting - Briefcase should be verifying that all the necessary tools are available, including differentiating between Xcode and the Command Line Tools.

I've just done a test on my M1 Mac, and it looks like it is possible to use the command line tools to sign; I wonder if this might be an x86-related incompatibility. Although the SO post mentions the specific install order, I don't think the order of installation is likely to be the cause - this should only be triggered be the tools that are currently active.

JonathanLoungani commented 1 month ago

Continuing to dig, I found the following page on PyInstaller which explains an issue with PyInstaller that produces the same error message.

PyInstaller breaks OSX code signing because it appends python code at the end of the binary. Appending data at the end of executable breaks the Mach-o format structure. codesign utility complains with the following messages. the __LINKEDIT segment does not cover the end of the file (can't be processed) file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment)

I'm not sure whether this is directly relevant.

JonathanLoungani commented 1 month ago

Current guess based on discussion during the sprint:

Something in the format of the template being produced by recent versions of Xcode are incompatible with the code signing tools from the older versions of Xcode.

Next steps:

nidhikamath2102 commented 1 month ago

If anyone is still facing issue even after checking XCode and iCloud Drive, the following worked for me!

Steps to follow:

  1. Check if XCode is updated (App Store), installed and active (xcode-select -p)

  2. Check if the directory where project is created is not synced to iCloud Drive (System Settings -> iCloud -> iCloud Drive)

  3. Check git config --global –list. I had git config core.autocrlf=true by mistake. Set to false (git config core.autocrlf false) or remove (git config --global --unset core.autocrlf) it. (Setting core.autocrlf=true is generally recommended for Windows users to avoid issues with line endings) Read More about this here - https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings#per-repository-settings

  4. Finally remove the build and clean the project. Do so as mentioned below, rm -rf build rm -rf ~/.cookiecutters/ briefcase build

This worked like a charm! Happy Coding!

freakboy3742 commented 1 month ago

@nidhikamath2102 To clarify - the issue you were seeing (CRLF handling) is a different way to manifest the same error message. The PyCon sprints have revealed at least 3 ways that signing can fail:

  1. The project drive is being mirrored on iCloud
  2. Git has core.autocrlf enabled
  3. Running on an x86_64 machine with an older version of Xcode.

These are all distinct issues, with different solutions - although they all manifest with the "Unable to code sign" error message.

JonathanLoungani commented 1 month ago

I was unable to build the stub project from the Mac OS app template on my machine, as described in this issue: https://github.com/beeware/Python-Apple-support/issues/220