Xcode 11, Command CodeSign failed with a nonzero exit code - xcode

Ever since updating (against my will) to Xcode 11, I'm getting this error when I try to build my project:
CodeSign /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app (in target 'pplight-ofx-098' from project 'pplight-ofx-098')
cd /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
Signing Identity: "-"
/usr/bin/codesign --force --sign - --entitlements /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/build/pplight-ofx-098.build/Debug/pplight-ofx-098.build/pplight-ofx-098Debug.app.xcent --timestamp=none /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app
/Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app: code object is not signed at all
In subcomponent: /Volumes/HDD/OpenFrameworks/of_v0.9.8_osx_release/apps/plus-pool-light/pplight-ofx-098/bin/pplight-ofx-098Debug.app/Contents/Frameworks/GLUT.framework
Command CodeSign failed with a nonzero exit code
I've tried cleaning my project, resetting my login keychain, and restarting my computer, but I still get this error... what to do?
I am building an OSX App using OpenFrameworks, not an iOS App. When I build it in Xcode 10.3 works fine with no errors.
The parts of this question that are unique is that this is for Xcode 11, not 10, and none of the answers for that other question worked for me!

I've resolved the same exact problem by:
Add --deep to the "Other Code Signing Flags" in the "Build Settings".
In the "Signing & Capabilities" of your target click on "+ Capability" in the top left corner and choose "Hardened Runtime".
Then turn on "Disable Library Validation" in the list.
I don't really know if there's any drawbacks by using this capability, however my application compiles and works fine both on macOS and iOS.

You can get this error if you have added a folder to your project as a 'folder reference' (the project will have a blue folder logo in Xcode)
Remove the folder (Trash)
Add folder and select 'Create Groups' instead of 'Folder Reference' at the dialog
Add Folder Dialog

I got the same error after I upgraded to XCode-11 this morning. Builds in the simulator but not on device.
This thread helped fix the issue which I summarized below.
https://stackoverflow.com/a/52628909/9286768
Open keychain access.
Lock the 'login' keychain. (right clicking on "login" in the upper left
panel)
Unlock it, enter your PC account password.
Clean Project in the product menu.
Build it Again.

I fixed this by adding --deep to Other Code Signing Flags in the Build Settings > Signing

I had the same issue for all my Carthage Frameworks, the solution is:
Under Target-> [AppName] -> General -> "Frameworks, Libraries and
Embedded Content"
Select "Do Not Embed" for the option next to the problematic
framework.
More info are in this thread
NOTE: this might not fully solved the issue, never forget to try clean the project, restart Xcode even restart Mac sometimes.

I solved the problem as follows:
After adding 2 ".png" files, Xcode (Version 13.2.1 (13C100)) would not compile anymore. I integrated these 2 files in a .rtf file (generated from Xcode) and I succeeded in compiling again. That's how it goes.

I fixed the problem by making sure the Code Signing Identity in Build Settings was correct - not just general Apple Development and then cleaned the Build Folder in in the Product Menu. When I ran it again it built without error.

I resolved a similar error in Xcode 13 by only changing my Base SDK to the latest SDK (i.e. iOS 15).

Related

Xcode 11.2.1 - Command CodeSign failed with a nonzero exit code

I'm working on a SFML app for macOS with the latest Xcode version.
I got a "Command CodeSign failed with a nonzero exit code" error when it tries to sign the SFML frameworks. I added these under "Link Binary with Libraries" and "Copy Files" in Target, under Build Phases. Before, I was working with my local frameworks under /Library/Frameworks, and it was working very well.
Now I need to create an archive .app.
I've tried a lot of things seen on other posts here (like lock and unlock my keychains), but nothing worked. Still got that error.
My SFML Frameworks in "Link Binary with Libraries"
/Users/lounesksouri/Library/Developer/Xcode/DerivedData/Squadro-gqwjbvsooypqaifxxyzhdrahkdpo/Build/Intermediates.noindex/ArchiveIntermediates/Squadro/InstallationBuildProductsLocation/Applications/Squadro.app/Contents/Frameworks/sfml-system.framework/Versions/A: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code
Ok, I solved my problem, after long hours.
It's a lot more simple to use the script already present in Build Phases tab, generated if you use the SFML App Xcode template (see here the original script). I had tried it at first, but it didn't work so I let it down.
But, in this script, the first three lines are not the good ones, for a normal SFML installation on macOS. We need to modify these lines with the good paths to the Frameworks and lib folders, as follows :
SFML_DEPENDENCIES_INSTALL_PREFIX="/Library/Frameworks"
CMAKE_INSTALL_FRAMEWORK_PREFIX="/Library/Frameworks"
CMAKE_INSTALL_LIB_PREFIX="/usr/local/lib"
FRAMEWORKS_FULL_PATH="$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/"
Secondly, there is still the code signing problem : the archive will created but we will get an error if we start the .app. The solution to this problem is to check Disable Library Validation under Target/Signing & Capabilities to allow the application to load plug-ins or frameworks signed by other developers.
Finally, if we create the archive and launch the application, everything goes normally, as planned.
I faced this problem with the new update of Xcode. I was reading your discussion, and did some accidental modifications. I am definetely not an expert but what I did fixed the problem so I did not receive tgis error anymore. So I added the sfml libraries (5 libraries), whose paths are written in build settings -> framework swarch paths. And this adding automatically added them in Embedded Frameworks under the Build phases section. What I did is unchecking the checkboxes of all 5 libraries "Code sign On copy". Thank you guys for giving me the path for "solving" the problem :))))
For the Code-signing issue:
Open a Terminal,
Go to the Framework folder (cd /Library/Frameworks) and sing them.
choose your identity
security find-identity -vp codesigning
sign them Frameworks!
codesign -s AD90FAFAFAFAFAFAFAF-YOURHASH-9D6 ogg.framework
codesign ... all the others
run and enjoy!

Flutter library not found for -ldevice_info, can't archive the ios app with xcode

when I try to archive the app or run in a real device, I always get below errors:
ld: library not found for -ldevice_info
clang: error: linker command failed with exit code 1 (use -v to see invocation)
but if I just run in a simulator, everything is ok, if I try to remove the device_info package, then it will also show another package not found:(
I am using the latest flutter dev sdk, and I have setup a valid iOS developer certificates.
Thanks!
It seems that the solution here in this SO post as mentioned in the comment works for this case:
In new projects, in the iOS part is necessary to adjust a few
parameters, such as signing, and that you can only do in Xcode.
So, try to open the iOS project with Xcode and try to build it from
there. You'll see better warning and error messages there, specially
regarding signing.
You can open Xcode and locate your project ios folder, or:
cd yourproject/ios
open -a Xcode .
Then select Product > Run in the menu.
Also, this GitHub post discussion could also be a possible reason for other cases. Try to check the following:
I was able to successfully archive with your pubspec.yaml.
Can you confirm you opened ios/Runner.xcworkspace and NOT ios/Runner.xcodeproj? See Better handle case where a developer
opens Runner.xcodeproj instead of Runner.xcworkspace
#10770.
Did you run flutter build ios before you Archived? See https://flutter.dev/docs/deployment/ios#create-a-build-archive.

Ad-Hoc codesigning for device succeeds in Studio, Fails in Jenkins

I have a Xamarin Forms application that supports Android and iOS. I've generated Jenkins builds to compile them. All of the Android builds work. The iOS Debug build compiles fine. The Ad-Hoc build, however, fails to build completely for an iPhone target. It appears to be failing during codesigning. It works if I target the iPhoneSimulator, but if I target iPhone device it fails.
Tool /usr/bin/codesign execution started with arguments: -v --force --sign 81088F8E194139DC4C6CE640716944E41FB0709F --entitlements "/Users/Shared/Jenkins/.jenkins/workspace/{project path}/obj/iPhone/Ad-Hoc/Entitlements.xcent" --deep "/Users/Shared/Jenkins/.jenkins/workspace/{project path}/bin/iPhone/Ad-Hoc/AppName.app"
bin/iPhone/Ad-Hoc/AppName.app : error : /Users/Shared/Jenkins/.jenkins/workspace/{project path}/bin/iPhone/Ad-Hoc/AppName.app: unknown error -1=ffffffffffffffff [/Users/Shared/Jenkins/.jenkins/workspace/{project path}/iDriverMobile.iOS.csproj]
If I open up the Solution in Visual Studio, right in the Jenkins workspace folder so it's using the exact same files, then compilations works fine, which is really frustrating.
Looking at differences between the two outputs, it seems that the working build (from Studio) has AOT output for all of the assemblies that looks like this:
Mono Ahead of Time compiler - compiling assembly /Users/Shared/Jenkins/.jenkins/workspace/{project path}/obj/iPhone/Ad-Hoc/mtouch-cache/32/Build/OpenNETCF.Google.Analytics.dll
The failing build has none of those. Instead, it has a couple lines that look like this:
MTOUCH : warning MT0095: Aot files could not be copied to the destination directory /Users/Shared/Jenkins/.jenkins/workspace/{project path}/obj/iPhone/Ad-Hoc/mtouch-cache/64/Build/Msym/Msym/tmp: Could not start process. [/Users/Shared/Jenkins/.jenkins/workspace/{project path}/AppName.csproj]
The worst part of all of this is that these builds did work, but then I restarted the Mac Mini that Jenkins is running on and things went downhill. I can't figure out what the difference is between what Studio is doing and the command line call to msbuild. They both point to the same binaries.
Additional Information
This still fails with the latest updates as of today (5/24/17). This is the environment:
Mac OS X 10.12.5
List item
XCode 8.3.2
Xamarin.iOS 10.10.0.36
Visual Studio 2017 Community for Mac 7.0.1 (build 24)
Mono 5.0.1.1
What doesn't fix it:
Creating a new Jenkins build
Changing the Jenkins workspace path
Opening up permissions (777) to the entire Jenkins folder
Enabling LLVM
Disabling all linking
Completely uninstalling and re-installing Jenkins
Using xbuild instead of msbuild
Swearing a lot
My middle finger
Try to delete the derived data folder in DerivedData of your app. It looks like YourAPP_ dasfdsfsdafdsasfdsaf, according to this from Apple Developer Forum.
The DerivedData data folder is located at ~/Library/Developer/Xcode/DerivedData/
If this does not work, all the symptoms point to a signing certificate (also called, signing identity) issue.
It seems like when it was compiled from command line, /usr/bin/codesign can not access signing identity 81088F8E194139DC4C6CE640716944E41FB0709F. It could be many different reasons, unfortunately:
keychain was locked
codesign is not allowed to access the signing
identity.
multiple identities exist in keychain and wrong signing
identity was selected
Wrong provision
profile was matched for Ad Hoc build.
Try to add following code snippets before running msbuild, assuming your signing identity is in keychain ~/Library/Keychains/login.keychain:
security unlock-keychain -p <password> ~/Library/Keychains/login.keychain
security set-keychain-settings -l -u -t 3600 ~/Library/Keychains/login.keychain
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k -p <password> ~/Library/Keychains/login.keychain
It is not a good idea to have keychain password stored in the build script, you can follow this guide to hide them.

How do you fix "code object is not signed at all In subcomponent:" in Xcode 6, Mac OS X Yosemite or Mavericks?

When compiling my application I'm getting the following error:
CodeSign /Users/pupeno/Library/Developer/Xcode/DerivedData/ProjectX-cynmgyozflnwbpamwnpsnhgshuyq/Build/Products/Debug/Project\ X.app
cd /Users/pupeno/Projects/ProjectX
export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
Signing Identity: "Mac Developer: José Fernández (G4PM7K38JH)"
/usr/bin/codesign --force --sign A21FB31766DDCBB28FBB4E4DD86E3743024A45F3 --entitlements /Users/pupeno/Library/Developer/Xcode/DerivedData/ProjectX-cynmgyozflnwbpamwnpsnhgshuyq/Build/Intermediates/ProjectX.build/Debug/App.build/Project\ X.app.xcent --requirements =designated\ =>\ anchor\ apple\ generic\ \ and\ identifier\ \"$self.identifier\"\ and\ ((cert\ leaf[field.1.2.840.113635.100.6.1.9]\ exists)\ or\ (\ certificate\ 1[field.1.2.840.113635.100.6.2.6]\ exists\ and\ certificate\ leaf[field.1.2.840.113635.100.6.1.13]\ exists\ \ and\ certificate\ leaf[subject.OU]\ =\ \"XHT4M2DATL\"\ )) /Users/pupeno/Library/Developer/Xcode/DerivedData/ProjectX-cynmgyozflnwbpamwnpsnhgshuyq/Build/Products/Debug/Project\ X.app
/Users/pupeno/Library/Developer/Xcode/DerivedData/ProjectX-cynmgyozflnwbpamwnpsnhgshuyq/Build/Products/Debug/Project X.app: code object is not signed at all
In subcomponent: /Users/pupeno/Library/Developer/Xcode/DerivedData/ProjectX-cynmgyozflnwbpamwnpsnhgshuyq/Build/Products/Debug/Project X.app/Contents/Frameworks/Paddle.framework
Command /usr/bin/codesign failed with exit code 1
I'm using two frameworks, Paddle and Sparkle and they are configured to sign on copy:
Looking for a solution to this problem I found many recommendations to do a --deep sign, which is officially discouraged by Apple (Using the codesign Tool's --deep Option Correctly).
I also found the article Code Signing and Mavericks which also explains that using --deep is wrong and offers an alternative: using a script to generate signatures for each framework. I think this is something that was needed before Xcode had the option to sign on copy, but I gave it a try anyway. It made no difference, I still get the same error. Looking at the logs, the bundles are getting signed with the "Sign on copy" option, so, adding that script caused them to get signed twice.
My code signing identity is configured as follows for the whole project and each target just inherits it:
I understand that's not the appropriate signature for Release, but for now, we are just trying to get this to build and run locally.
Any ideas what's wrong? Any ideas how to fix it?
I understand that
For me I had to go to the Project build settings and set Other Code Signing Flags to --deep. The problem was that my framework in the project was not signed.
For All who still are facing this issue, Please make sure 'Product Name' in build setting matches with 'Executable file' set in info.plist.
Generally when we duplicate exiting code, we simply change either product name or Executable file, and this mismatched creates a issue.
The problem was that the Framework, Paddle.framework, became corrupt. The symlinks were resolved to the files they were pointed to, so, compilation worked just fine, but signing didn't.
Re-downloading the framework and copying it into the project fixed the problem.
For me the solution was to re-Add a resource folder (checking Create groups instead of create folder references).
Adding ANOTHER thing to check if you get this error:
In the Build Phases pane for your Project's application target, make sure the Embed Frameworks phase comes before the Link Binary With Libraries phase:
I'm running macOS 11.2.3 and Xcode 12.4.
An Aside:
It's utterly ridiculous how fragile and broken code-signing remains. It's 2021 and this post alone has 87 different "fixes" to solve the same damn error message. There's just no excuse for wasting developers' time like this. Fix your IDE, Apple.
For me this problem was resolved by a simple "clean build folder" action, keyboard shortcut: shift+option+command+K.
I'll admit codesigning is still a black art to me, but in Xcode 6 I found that removing all of my signing scripts (which were necessary in Xcode 5, along with --deep flags) and additional signing flags, and just using the "codesign on copy" option in the Framework's Copy Files phase of the build worked flawlessly for me.
For me, it turned out that I had inadvertently added a bash build script to the target. Making sure I had no sneaky scripts accidentally copied into the target fixed the issue.
Product -> Cleanup build folder
Build/Compile project
for me, one of the frameworks I was including, had another of the frameworks marked as "embed and sign"... which you can't do... only the app should be doing that.
marking the grandchild framework as "do not embed" in the child framework, removed this issue.
I faced this problem after adding fastlane to upload screenshots to App Store Connect automatically. I had to remove fastlane from the project and clean the build folder to make it work again.
Using CocoaPods in the project it helped me to go to the Pods project, select a problem framework and set the correct developemtn team on Signing & Capabilities page or Build settings with All levels set.
In my case I both had a subproject and a subproject of that subproject (i.e. a sub-subproject) to which I had added the same Swift package dependency. Keeping it in the sub-subproject and removing it from the subproject solved the issue.
As shown by the number of answers here the causes for the error can be many.
In my experience building a complex project with multiple level of Frameworks, Static libraries from Swift packages and Pods you should follow these rules:
A Framework can't embed and sign another framework: only and App can do that.
A Framework can use a static library (from a Swift Package for instance) but the library must be present only in the Framework and not in the main App. If the same library is embedded in both Framework and main App, in some unknown circumstances, this error occurs.
Be sure to clean the build folder after each change to frameworks and library structure/embed

OS X app on Lion 10.7.2 Xcode 4.3 :: error: failed to launch <exe path> -- SBTarget is invalid

The app builds with zero errors and has a single line of output after Xcode displays "Running AppName : AppName"
error: failed to launch '/tmp/HungryMeProduct/Debug/HungryMe.app/Contents/MacOS/HungryMe'
-- SBTarget is invalid
The App will not run in Xcode.
This is my first OS X app. It was doing fine until
I changed the Project Name and the name of the xcodeproj file name recently.
ProjectName, Executable Name are the same.
Deployment Target 10.6
The executable at .../Contents/MacOS/HungryMe runs when I double click it.
Terminal window displays output.
The code signing identity remains my Developer Identity
In the schemes I see that LLDB is selected not GDB. Is this a debugger problem? What is SBTarget?
This happened to me, and the issue I had was the schema Target was correct but 64 bit was selected in as the architecture instead of 32 bit, for a 32 bit only project. Once I made the switch, it started working again.
GDB had the same issue but did not report it so elegantly, instead it reported "warning: posix_spawn failed, trying execvp, error: 86". It did launch the app but could not debug it.
This can easily happen if you debug without building the project, after switching the schema, or if the schema gets switched for you due to an external change to the project file (updating or reverting your source repository using git, svn, ...)
I tried everything metioned here. Nothing worked. It seems that I somehow imported the Info.plist twice. To fix it I selected the project and pressed the "Validate Settings" button. Afterwards it works for me.
Try to change Target's Architectures in Build Settings

Resources