Whenever I run 'build and archive' from XCode I get the following message:
Unable to copy dSYM file into archive.
Please make sure that your application has set the “Debug Information Format” build setting to “DWARF with dSYM File”.
I have checked my Debug format and it is set to the suggested value(DWARF with dSYM). Has anyone else ran into this issue, if so how did you fix it?
Try setting 'Generate Debug Symbols' to true in the build settings of the target you're trying to build and archive.
This solved the issue for me!
this worked for me ,i hope it help someone out there...
Goto to the build setting and search for "Generate debug symbol" and set it to Yes.
then search for debug information format in build setting and set "Debug information format" to "DWARF with dSYM file"
I just ran into the same problem, but I had an build script which removed the dSYM file before Xcode could. So it wasn't there and that was what Xcode was crying about.
I attached a screenshot, so perhaps the next one which runs into that problem can recover a bit quicker from that.
The 'Generate Debug Symbols' solution worked for me as well. After it worked once, I disabled the setting again, and I build & archive worked again, producing a file smaller by 700kb than the debug symbols enabled version. Not sure if this is actual savings after the app is on the app store, but it doesn't hurt!
That's how your build settings for both release and debug configuration should look like:
Generate Debug Symbols → Yes
Debug Information... → DWARF with DSYM
Deployment Postprocessing → YES
Strip Linked Product... → No
Strip Debug... → No
If there's still no luck, try check the Report Navigator.
The point is, dSYM file may be generated in another location, or not generated at all.
In my case, the dSYM file has not been generated, and there hasn't been a corresponding line that goes like "Generate Appname.dSYM ...in {path}"
But there's been Fabric installed, and it logged the fact of the dSYM file's absence:
Just filer the Report Navigator by "dSYM".
If dSYM is not generated in appropriate folder
Check environment variables, especially DWARF_DSYM_FOLDER_PATH and DWARF_DSYM_FILE_NAME.
To embed the dSYM within the app bundle, just set DWARF_DSYM_FOLDER_PATH to $(CONFIGURATION_BUILD_DIR)/$(EXECUTABLE_FOLDER_PATH) and DWARF_DSYM_FILE_NAME to $(EXECUTABLE_NAME).dSYM
Now the build should create dSYM for your target
Related
After successful Archive, while exporting the Archive to "Save for App Store Deployment", I got the following error:
"Symbol Tool Failed".
During the Export sequence, I have observed, "Binary and Entitlements" section, has two entries.
1) The app store targetAppName (5 Entitlements). with valid Provisioning Profiles.
2) One of the build files FTALDeviceDetailsViewController.o (o Entitlement) with Provisioning Profiles (none)
I bet the second entry here is what is causing the error. Here is the error log:
Any one know how to remove the second entry?
I found another interesting information, regarding this issue:
Unser Archive folder
ActiveLife\ 11-12-14\,\ 3.56\ AM.xcarchive/Products/Applications/ActiveLife.app/
I found following 3 files those are generated in response to second Entitlement file:
FTALDeviceDetailsViewController.d
FTALDeviceDetailsViewController.dia
FTALDeviceDetailsViewController.o
I have manually deleted these 3 files, and now I am able to generate .ipa file.
Now still mystery to me is; why are these files generated and how to fix the root of the problem?
I experienced the same "Symbols Tool Failed" issue yesterday. With the following more detailed error:
Archive upload failed due to the issues listed below.
Unable to validate your application.
The path '/var/folders/c6/wfv094t921j7q1bzhht5wtdnhvjv1/T/XcodeDistPipeline.blK/Packages/XXXXXX.ipa' does not contain a file.
The cause of the problem was that a third party library (*.a file) had accidentally been included in the "Copy Bundle Resources" "Build Phase". The give-away that this was the problem was that this *.a library appeared in the list of "Binary and Entitlements" screen when submitting the upload:
Ultimately the third party source code had been added to our workspace as a "Folder Reference" and someone had checked the 'target membership' for that folder. This resulted in the the third parties libary folder (which contained the *.a) being included in the "Copy Bundle Resources". Simply unchecking the 'target membership' box for the folder fixed the issue.
The reason for the issue is, some how FTALDeviceDetailsViewController.m file is ended up Copy Bundle Resources causing this is be treated as separate target.
When I delete the file from the Copy Bundle Resource, every thing worked as expected.
Now the mystery questions to me, what are .d .dia generated? This is up for further study.
Unchecking "Upload your app's symbols to receive symbolicated reports from Apple" option fixes the "Symbol tools failed" error when you Archive the app in Organiser window of Xcode.
I faced this too, and trying to find something wrong with the copy bundle resources, as the previous answers, I found a folder being copied, removing it solved the problem.
Basically some framework has been added to Copy Bundle Resources. Remove it to resolve the issue!
Could also be that there is a framework unnecessarily added in 'Embed Frameworks' in Xcode Build Phases
"Symbols Tool Failed" error can also be caused by this.
Xcode 13.1 - Check BuildTarget -> General -> Frameworks and Libraries. If something is marked as Embed And Sign it may need to be changed to Do Not Embed.
I am new to this iPhone development and i have almost completed my first application but when i try for creating an archive it gives an error lexical or preprocessed issue file not found But it runs fine in simulator and also has also tested on device. I have included SDwebimage architecture for lazy loading of image in table view.Can any tell me what is the issue?
Few things to try, Ensure the Framework and all it's headers are imported into your project properly.
Also in your Build Settings set YES to Always search user paths, and make sure your User header paths are pointing to the Framework.
Finally, Build->Clean and Restart Xcode.
Hope this helps !
UPDATE: According to SDWebImage's installation, it's required you make a modification to Header Search Path and not User header paths, As seen below.
Have you done this as well? I suggest slowly, re-doing all the installation steps from the beginning.
Spaces in a folder name in your header search path can cause this problem. Make sure the folders in your project do not have spaces in their names.
My project was building fine until I updated to Xcode 10.1. After the Xcode update, started getting Lexical or preprocessor Issue errors on build. Some XCDataModel header files could not be found.
This fixed the issue.
Go to Build Settings, Header Search Paths
Change the appropriate value from $(SRCROOT) non-recursive to recursive.
This ensures that subfolders are also searched for headers during build.
I had this same issue now and found that my sub-projects 'Public Header Folder Path' was set to an incorrect path (when compared with what my main project was using as its 'Header Search Path' and 'User Header Search Path').
e.g.
My main project had the following:
Header Search Paths
Debug "build/Debug-iphoneos/../../Headers"
Release "build/Debug-iphoneos/../../Headers"
And the same for the User Header Search Paths
Whereas my sub-project (dependency) had the following:
Public Header Folder Path
Debug "include/BoxSDK"
Release "include/BoxSDK"
Changing the 'Public Header Folder Path' to "../../Headers/BoxSDK" fixed the problem since the main project was already searching that folder ('../../Headers').
PS: I took some good screenshots, but I am not allowed to post an answer with images until I hit reputation 10 :(
I had this problem after changed project name. I used all the methods mentioned on the internet but still doesn't work. Then I realized that all the header files not found was from cocoapods, so I re-installed the cocoapods using pod install, and thus solved the problem.
Hope this could help.
In my case I was developing a framework and had a test application inside it, what was missing is inside the test application target -> build settings -> Framework Search Paths:
The value needed to be the framework path (the build output - .framework) which is in my case:
"../FrameworkNameFolder/" - the 2 points indicates to go one folder up.
Also, inside the test application target -> Build Phases -> Link Binary With Libraries:
I had to remove the framework file, clean the project, add the framework file again, compile and this also solved the issue.
The new version contain fix for this, feel free to update.
Or you can just replace
#include "iPhone_View.h"
with
#if UNITY_VERSION < 450
#include "iPhone_View.h"
#endif
Delete the unit testing from your project follow the below steps this will solve the issue.
select your project from the project navigator to open the project editor. From the target delete the test from the left side of the project editor and press the Delete key.
I know this is old, but I'm gonna chime in anyway because it may be useful to someone. If you can still see the file in Finder, then click on the file in your project and delete it, selecting "remove references" and not "move to trash".
Once the reference is removed, drag and drop the file from finder into your project again and it should sort itself out.
Just adding another thing that worked for me :
react-native link
Evidently my ReactNative files were no longer there. I could figure that out by clicking on
Build Phases -> Link Binary with Libraries ->
Then right clicking a file I knew was responsible for React, and clicking Show In Finder .
But nothing opened. So assuming the library went missing, I just ran the above command which relinked everything again.
Also if you havn't, try :
rm -rf node_modules/ && npm install
This happened to me after I renamed a file. For some reason it was still looking for the file with the old name. What I did was create the file that it was complaining about and added to the project. Then I did a Project->clean, then Project->Build and verified the error was gone. Then I selected the newly added files and deleted them. This removed all references and I no longer see the error.
I fixed mine. The fb sdk downloaded (from my browser) as 'FacebookSDKs-iOS-4.22.0' -- I just had to rename the folder to FacebookSDK. So now in Build
Settings --> Framework Search Paths
the path looks something like /Users/.../Documents/FacebookSDK (where as before it was /Users/.../Documents/FacebookSDKs-iOS-4.22.0)
Hope this helps!
For what it's worth, my problem was completely unrelated to the error Xcode was giving. I stumbled onto a solution by deleting the .h reference, compiling, adding the reference back and compiling again. The actual error then became evident.
I have tried to move the files in my project folder to a different folder and everything went ok, except that Xcode cannot find my Info.plist file now. This is the error I get.
could not read data from '/Users/jamiefraser/Developer/CocoaTouch Apps/MyApp/MyApp/MyApp/MyApp-Info.plist': The file “MyApp-Info.plist” couldn’t be opened because there is no such file.
The actual files location is
'/Users/jamiefraser/Developer/CocoaTouch Apps/MyApp/MyApp/MyApp-Info.plist'
I have checked the build settings for the project and they read
MyApp/MyApp-Info.plist
I have tried deleting the build folder and cleaning the project, but I always get this same error. I appreciate any help you can offer
Remove MyApp/ portion from build settings. plist file usually is located in the same folder ad project. You can always open project file in vi and edit it manually.
It is just a guess but it seems like one trailing /MyApp is too much in the location you are wanting to read from:
'/Users/jamiefraser/Developer/CocoaTouch Apps/MyApp/MyApp/MyApp/MyApp-Info.plist'
As opposed to the actual location:
'/Users/jamiefraser/Developer/CocoaTouch Apps/MyApp/MyApp/MyApp-Info.plist'
It would make sense to check out the URL / PATH variable you want to read from.
I had the same problem after trying to duplicate and rename a project.
In Build Settings, I had to fix two paths before I finally got it compiling successfully:
Under Packaging, Info.plist
Under Apple LLVM 5.0 - Language, Prefix.pch
I inherited some source code and am now trying to adhoc compile it.
However, I'm seeing this error message
CodeSign error: The entitlements file '/Users/teepusink/Documents/i_think_the_original_guys_path/Entitlements.plist' is missing
Where can I change that path? I do see that there exist an Entitlements.plist file and I've changed the Code Signing identity to mine.
Thanks,
Tee
Got the same problem and had to fix it manually in the XCode project file. XCode did not accept my changes via "Get Info".
make a backup first!
open your .xcodeproj file by right clicking the file in Finder.app and selecting "Show Package Contents"
open project.pbxproj
search for "/Users/teepusink/Documents/i_think_the_original_guys_path/Entitlements.plist"
delete the lines with CODE_SIGN_ENTITLEMENTS = "/Users/teepusink/Documents/i_think_the_original_guys_path/Entitlements.plist";
After that I was able to re-add the Entitlements.plist file and it showed up there with the correct path and the build process ran without errors.
You can change it by right clicking on your Target under Targets in Groups & Files, hit the 'Get Info' option. Select Adhoc from the Configuration dropdown at the top left, then change Code Signing Entitlements to the path of the Entitlements.plist file located on your computer.
Another easy way to fix a path is to just delete the file reference in your project, make sure the file is where you want it (move, copy, check out from the repository), and then (re)add the file/plist to your project.
I am compiling an IPhone application via command line (so no XCode options involved) and I am unable to get my symbol names to show when profiling with Instruments. I have tried several flags such as -gdawrf-2 and -g without any success. I have also tried using dsymutils to generate a .dSYM file but i have no clue how I'm supposed to use it so that failed aswell.
Any help will be greatly appreciated!
I Changed my project settings to not include the dSYM file while building:
Changing it to include the dSYM File helped the profiler desymbolize the symbols and fixed my issue:
I was still having issues with this.
My issue was I was able to see the dSYM file being generated, but Instruments wasn't picking it up.
To fix this, do the following:
Locate your dSYM file (should be in ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_TYPE]-[DEVICE-TYPE]/
With Instruments stopped, click on File -> Re-Symbolicate Document
Scroll down to the entry with your app name
Click "Locate" and choose the folder from step 1
Click the Start button to begin profiling
How Instruments obtains debug information:
Instruments obtains debug info from a .dSYM file which is normally generated automatically by XCode when setting Debug Information Format to DWARF with dSYM File combined with a checkmark in the Generate Debug Symbols option box. Setting these options will add an extra step to the XCode build process and generate a dSYM file after the application has been compiled. Every dSYM is built with a UUID that corresponds to a UUID in a Mach-O section in the binary that it's derived from. A Spotlight importer indexes the UUIDs of every dSym file that is in a Spotlight-accessible location on your Mac. Therefore SPOTLIGHT does all the black magic and is responsible of making the link between the .app you are running and its corresponding .dSYM file.
How to generate debug information and dSYM file without XCode:
Make sure you are compilig with –gdwarf-2 and -g flags. (Other flag combinations might work)
-g
Produce debugging information in
the operating system's native format
(stabs, COFF , XCOFF , or DWARF 2).
GDB can work with this debugging
information. On most systems that use
stabs format, -g enables use of extra
debugging information that only GDB
can use; this extra information makes
debugging work better in GDB but will
probably make other debuggers crash or
refuse to read the program. If you
want to control for certain whether to
generate the extra information, use
-gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below). GCC allows
you to use -g with -O. The shortcuts
taken by optimized code may
occasionally produce surprising
results: some variables you declared
may not exist at all; flow of control
may briefly move where you did not
expect it; some statements may not be
executed because they compute
constant results or their values were
already at hand; some statements may
execute in different places because
they were moved out of loops.
Nevertheless it proves possible to
debug optimized output. This makes it
reasonable to use the optimizer for
programs that might have bugs.
-gdwarf-2
Produce debugging information in DWARF version 2 format
(if that is supported). This is the
format used by DBX on IRIX 6. With
this option, GCC uses features of
DWARF version 3 when they are useful;
version 3 is upward compatible with
version 2, but may still cause
problems for older debuggers.
Generate a dSYM file using dsymutil. If the tool isn't recognized in command line, use spotlight to find it.
IMPORTANT: Place .app file on your mac HD before you generate the dSYM if you are working on a networked drive.
dsymutil MyApp.app/MyApp -o
MyApp.app.dSYM
Place the .dSYM file on the mac's local drive and run Instruments as you normally would.
Resettig spotlight's indexing:
If symbols aren't shown, it might be because spotligh is bugged. You can try reseting spotlight's indexing by adding your folder containing the dSYM file (or even your drive) to the “Prevent spotlight from searching these locations” in the spotlight preferences and then removing it right away.
In Xcode 4.5 you can choose to Profile from Debug or Release builds. Release defaults to stripping the symbols when copied to the device. It's very easy to switch to the Debug configuration for profiling without breaking your release configuration. To do that, select Product -> Edit Scheme from the XCode menu. Select "Profile" from the list of schemes that comes up, and then select the correct Build Configuration for that.
Or you could make a separate release/profile configuration and use that in your Profile section of your scheme. How to add a separate build configuration is described in the XCode User Guide.
With Xcode 6 Instruments you can provide dSYM file as follow:
File -> Symbols... menu (when profiling is stopped)
select your app and press Locate button
select path which contains dSYM (usually ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_CONFIGURATION]-[TARGET_PLATFORM]/). Tip: You can copy this path from terminal and use OS X shortcut ⌘+SHIFT+G in dialog.
Also Instruments will ask you if it should use selected path to try load dSYM for this app in the future. Answer Yes :)
Spent three days trying to figure this out for Xcode 7.1/7.3...
Changing the deployment target to the latest version (9.3 at the time) fixed this issue for me. My company targets 7.0 so I will probably have to create a custom Scheme for profiling the code in Instruments to avoid having to change the target (or forgetting to change the target) when we do a production release.
Seems like it's probably a bug if dSYMs fail to work based on the deployment target?
The problem is that spotlight cannot find the .dSYM files.
This is because Apple changed the location of the DerivedData folder.
The DerivedData now goes in ~/Library
Spotlight will not index ~/Library and as far as I have been able to establish, cannot be made to index it either (e.g. mdimport is ignored).
A work around to get symbols in your profiler, is to simply copy the data outside ~/Library e.g. your home directory will do fine.
I used this command line:
$ cp -r ~/Library/Developer/Xcode/DerivedData/AppName-xxxxxxxxxxx/Build/Products/Release-iphoneos/ ~/
When you kill your profiler, and start a new profile run, you will see that the symbols are available again.
Check the build log and make sure that your -g switch is getting through to the compiler - it's easy to get this wrong when changing settings at the project and/or target levels for different build configurations etc.
Another work around in the version of Instruments that comes with Xcode 4 is to use the Re-Symbolicate Document menu item under the File menu for Instruments. This menu item to allows you to use the symbols located in the .dSYM file in ~/Library/... directory.
In my experience, this is usually because "Profile" has been called before the most recently modified version of the app has been installed on the target device.
Try running the app on the device/target, then calling "Profile" again after it has been reinstalled.
I got this problem because the XCode project was on a network share where Spotlight wouldn't find the dSYM files. Make sure it's on the local drive.