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.
Related
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
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
My application is not seeing source code for a library:
If I "Jump to definition" on a library method, XCode takes me to the .h file but says there is no .cpp counterpart
When debugging, I see no source code and most of the call-stack is missing for the library:
I have made sure "Show disassembly when debugging" is UNchecked
I built the library as DEBUG and then packaged up the headers+.a file into a SDK dir. So I guess I need to either copy the debug files into that SDK dir as well, or tell my application where to look. I'm not sure how to do either.
To clarify, my application project doesn't maintain a reference to the library project, only to the .a files and the header dirs. This is because the library project is created by CMake and I don't want to modify it.
First of all, you should check the .debug_str section of your static library to verify it contains the appropriate debug information.
Try running this command on the terminal:
xcrun dwarfdump /path/to/library.a | grep "\.m"
You should see a bunch of your source (.m) file paths printed out. Theoretically, this is where Xcode is going to look when you stop in the debugger, so make sure the paths here are correct. If you don't see any paths, you will need to pass an appropriate debug flag (e.g. -g to the compiler when building your library.
If the paths are somehow incorrect, or you want to point them to some other location, you may be able to modify them as part of the build process in CMake, for example to make them relative to your project directory. Try looking at "Make gcc put relative filenames in debug information", which uses CMake to adjust these debug paths.
I'm trying to add the openjpeg library to my XCode 4 project so that I can compress images taken by the iPhone's camera to jpeg2000.
I built the static library (libopenjpeg.a) using Cmake on OS/X. (I'm guessing this may have been the first error, that it needs to be built by XCode so it's built for iPhone architecture and not OS X).
I have the library added in the Link Binary with Libraries of my target.
The project builds successfully but I can't seem to import any of the headers from the library into any of my Objective-C classes. I've tried manually adding the folder that contains the libopenjpeg header files to the User Header Search Path but that did not seem to do anything.
Any suggestions?
for the simplest solution
Import the head files to you project's source.
You can still build it on the command-line with CMake, you'd just have to modify the CMakeLists.txt file so the right flags are passed when compiling.
However as Gavin indicates, it may be simpler just to drag the header and source files from the library into your Xcode project, and forego the building of a static library.