When I compile my swift framework MyFramework I makes so that Xcode produces MyFramework.framework (the compiled framework) and MyFramework.framework.dSYM (the dSYM file).
By running dwarfdump myframework.framework.dSYM/Contents/Resources/DWARF/MyFramework I've noticed that all the paths to the source files are absolute paths.
This makes it impossible to share these two artefacts (together with the source code) with my colleagues and allow them to use the compiled framework and being able to debug their code properly. More precisely they are not able to step-in inside the framework with the debugger.
For this reason they need recompile the framework which is very inconvenient.
Is there a way to modify the DWARF to edit these paths or even better to convince Xcode to use relative path in the DWARF file?
While I'm not aware of a way to change the paths stored in the dSYM or to make them relative, I can offer a way to work around the issue and be able to debug with those symbols on an arbitrary machine with source code in a different base path.
Once you find out what the original path is (e.g. /Users/rob/src/Project), and you have the code for that library in e.g. /Users/luka/Sources/Project, then you can issue this lldb command, which will replace for that session of the debugger the original path with your path:
settings set target.source-map /Users/rob/src/Project /Users/luka/Sources/Project
Unfortunately you'll need to run this command for each debugging session. To do that, you can create a breakpoint in your main, which runs that command and continues execution without stopping.
To find the original source path you can either use dwarfdump as you mention, or you can look up a symbol you know is in that binary from lldb with im loo -v -n MySymbol or through other parameters of the command (depending on the type of symbol you're trying to use).
This problem has been driving me crazy, and I can't work out how to fix it...
Undefined symbols for architecture armv7:
"_deflateEnd", referenced from:
-[ASIDataCompressor closeStream] in ASIDataCompressor.o
"_OBJC_CLASS_$_ASIDataDecompressor", referenced from:
objc-class-ref in ASIHTTPRequest.o
"_deflate", referenced from:
-[ASIDataCompressor compressBytes:length:error:shouldFinish:] in ASIDataCompressor.o
"_deflateInit2_", referenced from:
-[ASIDataCompressor setupStream] in ASIDataCompressor.o
ld: symbol(s) not found for architecture armv7
collect2: ld returned 1 exit status
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 failed with exit code 1
I think it has to do with:
ld: symbol(s) not found for architecture armv7
But I have added: libz.1.2.3.dylib and it's not helping, anyone got any ideas?
Common Causes
The common causes for "Undefined symbols for architecture armv7" are:
You import a header and do not link against the correct library. This is common, especially for headers for libraries like QuartzCore since it is not included in projects by default. To resolve:
Add the correct libraries in the Link Binary With Libraries section of the Build Phases.
If you want to add a library outside of the default search path you can include the path in the Library Search Paths value in the Build Settings and add -l{library_name_without_lib_and_suffix} (eg. for libz.a use -lz) to the Other Linker Flags section of Build Settings.
You copy files into your project but forgot to check the target to add the files to. To resolve:
Open the Build Phases for the correct target, expand Compile Sources and add the missing .m files. If this is your issue please upvote Cortex's answer below as well.
You include a static library that is built for another architecture like i386, the simulator on your host machine. To resolve:
If you have multiple library files from your libraries vendor to include in the project you need to include the one for the simulator (i386) and the one for the device (armv7 for example).
Optionally, you could create a fat static library that contains both architectures.
Original Answer:
You have not linked against the correct libz file. If you right click the file and reveal in finder its path should be somewhere in an iOS sdk folder. Here is mine for example
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/lib
I recommend removing the reference and then re-adding it back in the Link Binary With Libraries section Build Phases of your target.
I had a similar issue last night and the problem, was related to the fact that I had dragged a class from the Finder to my project in Xcode.
The solution was to go the the Build Phases tab and then the Compile Sources and make sure you drag the class to the list.
I had a similar issue and I had to check "Build Active Architecture Only" on each of the Project configurations (Debug, Release and Deployment) and in the Build Settings of the Target.
Another possible cause of "undefined symbol" linker errors is attempting to call a C function from a .mm file. In this case you'll need to use extern "C" {...} when you import the header files.
Linker error calling C-Function from Objective-C++
I had a similar issue with that. The class name after _OBJC_CLASS_$_ was actually my class. The reason was I didn't tick "Add to Target" when I drag the source code files into navigation list.
My solution was:
delete the class from the navigation list and choose "remove reference only"
drag the source code files again and make sure the tick box for "add to Target" is ticked. The tick box is just under "Copy if needed" and "Create group".
There is usually a alias without the version identifier that is linked to the current version, in this case libz.dylib is linked to libz.1.2.5.dylib. Use the base alias instead of the versioned one.
I had the same problem when I use admob library, I fixed it changing "Architectures" to "Standard architectures armv7, armv7s" without including 64-bit.
Under Target -> Build Settings -> Apple LLVM compiler language:
setting 'C++ Language Dialect' and 'C++ Standard Library' to Compiler default helped solve it.
I only added the libz.1.2.5.dylib to my project and it worked like a charm.
Steps -
Go to Build Phases.
Link Binary With library - use the '+' button to choose frameworks and libraries to add.
Select libz.1.2.5.dylib from the list.
Build and run.
I had a similar issue and saw errors related to "std::"
I changed Build Settings -> Apple LVM 5.0 - Language C++ -> C++ Standard Library
from libc++ (LLVM C++ Standard Library with C++11 support)
to libstdc++ (GNU C++ Standard Library)
If you have the flag -ObjC under your Target > Build Settings > Other Linker Flags and you're getting this issue, consider removing it. If you intentionally added it because you need to load some Obj-C code from a static library that wouldn't normally be loaded otherwise, IE, an Obj-C category, then you should use -force_load <path> instead of -ObjC.
<path> should be relative to your Xcode project directory. IE, if your directory structure looks like this:
iOSProject
+ iOSAPI.framework
+ iOSAPI
+ iOSAPI.xcodeproj
Then you should have this flag set for Other Linker Flags:
-force_load iOSAPI.framework/iOSAPI
If you want to include multiple libraries like that, then you should include a separate -force_load line for each of them.
-force_load iOSAPI.framework/iOSAPI
-force_load another.framework/another
Probably some classes are missing from your target. This usually happens when you rename/remove/add new classes files to your project. To fix add the newly added classes to some targets.
Select the class in the Project Navigator (right sidebar) , open the Utilities sidebar (right sidebar), from the Utilities select the File Inspector (file like icon), under the Target Membership tab tick your targets. This is all to avoid the "Remove reference" and add again with ticking "Add to targets" trick.
So: Select Class -> Utilities (File Inspector) -> Target Membership -> Tick the targets you want.
I have have multiple #interfaces in the .h file and hadn't yet included the all of the corresponding #implementation directives. Make sure that they are all balanced out.
Here's how I got this problem:
I added a .h, .m and NIB from another project by dragging them onto my project navigator. Xcode didn't add them to the Build Phases properly.
Check my answer because I had a similar problem that I was able to solve by doing some steps.
if you're dealing with the iOS5 upgrade, I found that for compiling a project written to target 4.3, I could just rename libz.1.2.3.dynlib in the Project Navigator to libz.1.2.5.dynlib and it compiled.
My iPhoneOS50SDK/usr/lib folder has no libz.1.2.3.dynlib--don't know whether it's a beta thing or just natural upgrade.
Go to your project, click on Build phases, Compile sources, Add GameCenterManager.m to the list.
This fixed my problem: The dependency I am using is not supporting armv7. So I had no other option than to remove it. Armv7 is used for only very old iphones anyway (like iphone 4).
Go 'Build Settings / All'
Set 'Valid Architectures' to 'arm64 arm64e'
I didn't find this suggestion here so here it goes:
if your project has more than one target (ie one for OSX and one for iOS) then you must link the relevant libraries for each target.. so for example in my case I needed AudioToolbox.. I had to add it once for OSX and once for iOS (under the frameworks folder, you must have a duplicate of each library for each target.. if you see only one.. then that's a red flag)
I was facing an issue with PJSIP libraries,
Tried the following in other linker flags in project and able to resolve the error:
-framework
Foundation
-framework
UIKit
Above linker flags are used in Siphone Project over github. These settings will help you resolve problems related to linking of C++ libraries.
Finally i've figured it out, I solved this issue by adding absent framework to target->Build Phases->Link Binary With Libraries
I once had this problem. I realized that while moving a class, I had overwritten the .mm file with .h file on the destination folder.
Fixing that issue fixed the error.
I received the 'Undefined symbols for architecture armv7:' error when trying to compile a project that had the target build setting for 'C++ Standard Library' set to 'libc++' (necessary as the project was using some features from C++ 11), and the project included a sub-project that had the same setting set to 'libstdc++' (or compiler default as it is currently).
Changing the sub-project's 'C++ Standard Library' setting to libc++ fixed it, but only after first setting the deployment target for the sub-project to 5.0 or above (5.0 is necessary for libc++).
I give you more suggestions that you can check when other common suggestions are not help.
If you link with other project(libxxx.a) you might sometimes meet strange problem which you can find the symbol with tools like nm but they just can not find the symbols in ld. Then you should check if the two projects are built in the same flags, some of them may affect the binary format.
check c++ compiler.
check c++ dialect setting.
check c++ runtime type support. (-frtti/-fnortti)
check if there is .a with the same name appears elsewhere, could be beyond the wanted file in the link path list. remove them.
I got this problem when I run app on iphone5s, it was solved by add arm64 to Architectures.
I had the same problem. I tried every thing from the huge list of answer but in the end my problem was:
I'm working with openCV so I need to combine C++ code in my code. To do this you should change the files which use objective-c and C++ to .mm
I didn't changed one file and this file has no connection to the C++ code but I had to change it.
I had this issue, when installing shareKit. It worked in the simulator, but not on the device. I removed -all_load from the Other Linker Flag and everything works fine in both simulator and iphone device.
In my case, I'd added a framework that must be using Objective C++. I found this post:
XCode .m vs. .mm
that explained how the main.m needed to be renamed to main.mm so that the Objective-C++ classes could be compiled, too.
That fixed it for me.
I use to face that issue when the module (file .m) is not in the target that I am working with.
For me the problem was that i forget to set value for my constants in the .m (implementation)
file const kFooKey = #"Foo";
I also added files through Dragging and Dropping. What I did, I removed references of all the files (Excluding frameworks) then added them again properly via Add Files To Project option, problem gone.
Some libraries require the -all_load linker flag when linking to an Xcode project. However, this leads to a linker error if there are symbol conflicts among libraries. The solution is to use -force_load, which effectively lets you use -all_load on some libraries, but not on others.
However, this in turn leads to a new problem, at least for me. Whenever I use -force_load with a relative path to a library, the linker always finds symbol conflicts between the library and itself. It appears that the linker thinks that the library with its absolute path and the library with its relative path are different libraries, and therefore finds conflicts between the library and itself.
I can avoid this by using an absolute path with the flag. But this is not a wonderful solution, as it is convenient to keep source code for libraries within my documents directory. But the path to the documents directory will be different on other machines.
Question: Can anyone get force_load to work with a relative path to the library?
EDIT: for background information, see this question
With Xcode 4, if you include the library project into your app project, then you can add this to the Other Linker Flags:
-force_load $(BUILT_PRODUCTS_DIR)/<library_name.a>
You still need the dependency, and you need to add the library in the Link Phase list of frameworks and libraries too.
EDIT: Apple now says as of some Xcode 4 release that you can simply use this linker flag: "-ObjC" to get libraries with categories to properly load. That flag is working just fine for me in Xcode 5. People are still up voting this answer, but I suspect that the -ObjC flag is the best solution now.
This worked for me. Like the above answers you still need to include the library in the project.
-force_load $(SRCROOT)/pathToLibraryFromProject/libname.a
For the path it's just the folders in your project that lead to where you put your library, for example BaseFoler/Subfolder/libName.a.
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.
The motivation for this question is me trying to get LDAP functions to work with an iPhone application which is a project I'm attempting for part of my dissertation.
When I was developing the application I used the ldap.framework framework that is part of Mac OS X. This works fine in the simulator, but when I try to now get the app on a device it tells me that I'm not allowed to use this framework.
After some research I found that I could build openldap using the arm architecture and add the static library to my application destined for my device.
I eventually managed to compile configure and build openldap by setting variables as mentioned here and using the following commands...
Ade$ ./configure CC=$DEVROOT/usr/bin/arm-apple-darwin9-gcc-4.0.1 \
LD=$DEVROOT/usr/bin/ld --host=arm-apple-darwin --with-yielding_select=yes
Ade$ make depend
Ade$ make
I was told that the file I'm looking for will have an extension of '.a' so I searched for a '.a' file that mentions ldap...
Ade$ sudo find / -name *ldap*.a
Password:
/Users/Ade/Desktop/openldap-2.4.16/libraries/libldap/.libs/libldap.a
/Users/Ade/Desktop/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a
So I assume these are the files I need?
My question is what do I do next? I know I need to add the library to the Xcode project and probably add a load of '.h' files too?
If anyone can give me a pointer to documentation or shed any light on the next stage I would be really grateful.
Many thanks,
Ade
ps. I have also talked about this process on my blog at www.greenpasta.com.
I've done this same thing to build an LDAP client for the iPhoneOS 2.2. You just to drag the .a into the "link with libraries" build stage. I recommend using the regular (non _r) version of the library, unless you specifically need reentrancy on your ldap stuff (which I don't recommend). You can also add the .h's to your project, which is generally the easiest way to access them.
Simply drag the .a files into the Xcode project and choose "copy files into project". I'm not familiar with OpenLDAP but I think the _r version is just a threadsafe version. I would recommend using that and not copying the other. You should probably not copy both files into Xcode or you will get link errors.
Then do the same for the .h files that define the client APIs of OpenLDAP - again I'm not sure which these are but I'm sure you can find out easily.
I would advise organising the .a and .h files together in a Xcode group under resources.
Include the header files in your source and you should be good to go.
You may also need to add -lldap to your linker command (in the build settings pane).