We have a rather large (and old) project, and we need to debug into a C++ function in a library that has not been touched for ages (64 Bit requirements you ask? How did you guess!)
But all we get is assembly code at that point.
It is further complicated by the fact that the library in question is build by some ancient CMake wizzardry.
My current main question is: if dsymutil --symtab does not list anything, does that mean there is no debug information in the .a file?
Or is there another, foolproof way to find out if DWARF debugging information has actually been generated?
I am asking, because on a sample project for a static lib I created, I see a symtab in the .o files, but not in the resulting .a file.
It turns out that dsymutil does not work well (or at all) with static libraries.
Using ar -x to extract the .o files and then using dsymutil on them appears to work, and thus solve my issue
Related
Thank you in advance. I have a static library, say libpics.a. I want to see its contents, such as the code of that library. My static library has one .h file and one .a file, i can see content of .h file, there is only one method, but i can't see the content of .a file. After some search i can just find that, .a file contains the coding part of or implementation of .h file's method. I am new to iOS development, the code in that .a file, i want to extract it, and use it.
I tried searching about how to open static library, but most of time i got search related to how to create static library and how to use it etc. But i just want to open static library file and just want to see the code in it's implementation file.
I read something about nm and ar tool, but i don't understand that where to apply that code.
something like this
nm -C libschnoeck.a | less
or
ar -t libsamplerate.a
after installing command line tool, i wrote
ar -x phpFramework.a
code in terminal as per suggestion by Владимир Водолазкий. i got below lines..
ar: phpFramework.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: phpFramework.a: Inappropriate file type or format
You cannot see source code inside static library, just due to there are NO source codes there. Static Library in IOS like in any other Unix-like system contains set of compiled procedures/functions/methods.
Just take a close look to the Xcode log when ordinary project is building. You can find that first, *.m files are compiled into *.o format - it is actually binary format (which is different when source file is compiled for use in Simulator or on native device). Then these *.o files are linked into application. (Please do not blame me for this simplistic explanation %-))
In fact static library is just a set of such precompiled *.o files. It is shipped by developer/owner to save your time on compilation or/and protect source code from modification. So you can only use it with the help of external calls, which are documented in .h files or you can extract separate modules (.o) from there and link it into your application "manually".
The code used to create the library is compiled into object files that are linked into the .a file. The .a file does not contain code and you can't get readable code from the .a file.
However to use the library you do not need the code, just include the library in your Xcode project as per the Xcode documentation and #import the headers into your code so that the compiler knows what is in the libraries.
During the link phase of your project the linker will look at the object code generated from your code and the find unresolved symbols which it will then look for in the library and only pull in the objects from the library that are needed. (One benefit of static over dynamic libraries)
nm will list the symbols that have been defined in the library and which your code can call.
I am testing an image capture library that sent over their code library as a regular header file and a file ending in a "*.a" extension. I am not familiar with using a file in this format and can't seem to find the right "magic" to search for.
What does this file extension stand for?
What if any extra steps are needed to get it integrated with my XCode project?
Maybe a bit more of theory can get you in the right track so you'll know how to search next time:
.a files are archives of object (.o) files. These object files are generally produced by an assembler, compiler, or other language translator; They contain machine code that is usually not directly executable, but are used by linker tools to generate an executable or yet another library by combining parts of these object files.
Another important thing you should know is that since these files contain machine code, they must have been compiled for the correct architecture you're targeting for (ex.: armv7, i386, etc). That can be the reason why sometimes you will be able build your project for one device but not to another if you don't have the right set of files for the targeted platform (e.g. iPhone simulator vs. actual iPhone).
It is also possible to have "universal binaries", which are files that in turn package together archives of object files (.a) for different architectures (e.g. using tools such as lipo), so that the same library file can be given to the linker for multiple architectures. Or, you may have a different linker configuration for each target (e.g. using conditional build settings in XCode). All of these files can be analyzed with certain tools (e.g. "file", "otool", "lipo -info", etc), and each has several parameters to play with. Debuggers will also check the symbols within these files for their own purposes.
When you drag the '.a' file to your project's directory within Xcode, you can notice that it will automatically add this file to the list of "Link Binary With Libraries" items under your target's "Build Phases".
Since the header files allows us to separate certain elements of a program's source code into reusable files, that commonly contain forward declarations of classes, subroutines, variables, and other identifiers that are needed for reference during the compilation step, it is common to have libraries provided as archives of compiled objects (.o) in ".a" files along with their respective headers. For instance, as soon as you include the headers files in your XCode project, the editor will provide auto-complete for these new functions.
Sometimes, you might also consider having the actual source code of the library instead of binaries inside your project as this * might * make debugging easier in case an unexpected behavior is happening inside that "library" package. Many times this is not an option though (when you have no access to the sources) when the binary distribution is made in purpose to hide implementation details (commercial libraries).
.a stands for archive. It is also known as a static library. I believe you should be able just to drag it and the header files into Xcode. Xcode should pick up the right thing to do from its extension.
Example, see appr. from 30 sec here
http://memention.com/ac3dreader/usage/quickstart.html
Another example from Google Analytics, under Setup
Drag GANTracker.h and libGoogleAnalytics.a from the SDK's Library directory into your new project.
https://developers.google.com/analytics/devguides/collection/ios/devguide
After reading this awesome post by Tristan, where he compiled FreeTDS for use in iOS, I attempted to compile UnixODBC for use in iOS. I was able to get it to compile, which is great.
However, when I compiled FreeTDS, I had a .a file that I was able to easily bring into XCode (along with a few .h files). This time, the compiler didn't produce a .a file. Instead, it produced a .la and a .dylib file. So far, I have not been able to use these files in my iOS project.
If I could accomplish any of the following, I think my problems would be solved:
1. Re-compile UnixODBC so that it produces a .a file, or
2. Convert either the .la or .dylib to a .a file, or
3. Import either the .la or .dylib to my project, so I can use it in the same way I would use a .a file.
So far, I am clueless as to how I would do any of these things (or if it's even possible). Can anybody please help me out?
Thank you!
-Rob
.dylib files are dynamically linked libraries, whereas .a files are statically linked ones (just google these two expressions). .la files are irrelevant now, they're not essential, and they don't contain any code,
If the configure script of UnixODBC supports it, you can specify the --enable-static --disable-shared options to enable building an .a archive and not a dylib. If the configure script doesn't accept these flags, then you can just go ahead a compile the source files (it will be done by configure), then instead of taking the resulting dylib, use the ar command to put the .o object files together to form a static archive.
I'm working on an iPhone app with Monotouch. In my app, I have to use a static library provided by 3rd party. This library is for Xcode and written in Objective-C. I bound it with Monotouch using Binding Project Template. When I add the resulting dll to my project it compiles fine, but when I use a class from the library it fails to compile with the following error:
Duplicate symbol _DeleteCriticalSection
So what can I do? Is there any way to remove the conflict?
Thank you in advance.
I've seen similar things inside FAT libraries where some files were duplicated, leading to duplicate objects. You can try to see if this is the same issue, e.g. if your library is named mystaticlibrary.a
$ nm mystaticlibrary.a | grep DeleteCriticalSection
Now it can be normal to have the symbol multiple times if you have a FAT library (more than one architecture). To see if that's the case do:
$ file mystaticlibrary.a
You should have the symbol for each architecture. If you see more symbols (e.g. 3x DeleteCriticalSection but only 2 arch) then you have a similar issue.
The fix (if it's the same issue) was to split the FAT library (lipo tool), then each architecture specific library, then re-merge everything (arch then FAT).
Your best bet might be to contact your library vendor and ask him for a fixed library (something was likely wrong in the build process). Give them the above command output and they'll likely find out what went wrong.
I am linking a static framework for iOS, against an armv7 ios 6 application, I suspect that the original binaries are from XCode 3.x and were compiled with GCC, and that I'm now linking it using CLang compiler. I do not have the source code for the framework, only the binaries:
(null): warning: (armv7) /.../DerivedData/.../armv7/HardwareObjectFile.o unable to open object file
I get 69 warnings like the above, one for every .o file linked into the static framework.
Is this warning serious for any reason? I have simplified the giant path which appears to indicate that the binary files in the library have hardcoded a path in "/Users/somedeveloperthatisntme" that could hardly help but Not Exist since I'm using this library on a computer that doesn't even have a folder named "Users/somedeveloperthatisntme".
Dsymutil appears to be a tool to "manipulate archived DWARF debug symbol files", although I know precisely nothing about what it is and what it does, notwithstanding the thorough documentation from Apple, which tells me what, but never ever, why. What is it doing, and what will this warning mean for me? I suspect I need a new library/static-framework from the vendor to clear this up?
Update: I am unable to solve this and it appears the cause lays with very old binaries compiled by a very old XCODE version, shipped as part of a mobile framework from a third party vendor. The issue in this case would be resolved by having that vendor rebuild their library, something I asked them to do because the warnings drove me nuts, but which they seem unable to do. In the end I ditched their technology and replaced it with something else. (Grin)
These errors are to do with the architectures you are using and the resources you are referencing. I don't understand the reasons myself, but if you want them to go away, go to Build settings, then Build Options and then select Debug information format and select DWARF.
I am on the other side of this, building a library for others to use, and I was able to alter the library project by setting 'GCC_GENERATE_DEBUGGING_SYMBOLS = NO' in the Build Settings to make those warnings go away in an Application project that consumed the output framework.
This isn't a solution to your problem, but if you're in contact with this vendor, you could pass this along.
The other answers contain helpful information but I wish to put the real answer down succinctly:
You can not fix this, and the meaning of the errors is simple: The current linker sees these library files as containing elements that can not be opened.
To solve the warnings, contact the vendor and get a recompiled library that has been rebuilt with a later version of CLANG.
What I did was just delete the /Library/Developer/Xcode/DerivedData folder and it fixed everything for me.
Another reason these warnings could occur is because of incorrect symbol stripping settings for release builds in a project. Contact the author of the framework and tell them to make a new binary with the proper symbol stripping settings.