I am a new iOS developer. I got a very basic doubt. I read at many places that we need to ship our .h file along with a .a file for a static library.
And .a files are compiled libraries, having entire implementation, which developers cannot read themselves, just to safe-guard implementer code.
And we need .h file to know what public functions are available. but then why cannot Xcode just decode .a file and use it directly instead of shipping another .h file. Xcode doesn't need to show the .a implementation to developers, but instead can suggest developers with publicly available methods.
I dont see any logical reason why Apple didnt do this way. I am sure there is definitely a strong reason for shipping .h files. I want to know what could be the reason?
An .a file is simply an archive of one or more .o (object) files. Object files contain the compiled machine code (for one specific operating system under a specific CPU architecture). The original source code is "lost".
The fact you probably didn't know about: object files can contain binaries compiled from an arbitrary programming language. An .h file is C/C++/Objective C specific. It contains the data types and function prototypes you need to be able to use the functions/data types/... contained in binary form in an object file in C/C++/Objective C. You could e.g. write a Pascal library, compile it to a .a file and use that code in your Objective C program using an appropriate header (.h) file.
You could also have only one header file (.h file) but e.g. 6 different .a files: One compiled for Mac OS X 64bit, one for Mac OS X 32bit, one for Linux 2.6 64bit, one for Linux 2.6 32bit, one for FreeBSD and the last for OpenBSD.
And last but not least, it wasn't Apple who decided to go that way, .a and .o files can be found on (at least) any Unix-like operating system and header files are the standard in C since the very first days.
Usually if you port a library from Mac to Linux, you can use (most of) the code and the header file but have to compile a separate .a file containing the object files compiled for Linux.
the .a files are collection of compiled .c, .c++, .m etc files. Decompilng those files just to get the names / signatures of functions would a) be dodgy on moral/privacy grounds and b) be a lot of work. The .a files aren't byte code or something similarly easy to reverse engineer - they are machine code.
Even if you did reverse engineer the "source" from those compiled files, they wouldn't contain the actual method names, or signatures, or anything recognisable.
Related
I am trying to use Berkeley's SPICE tool in an iOS app, but am having trouble compiling it for iOS.
It is a command-line program that I can call from a terminal like:
./spice3f5 <arguments>
Which works well, and I would like this functionality in my iOS app, but I don't think I can just copy the executable over to Xcode and call it from Swift.
I've done some research and found the following:
There is an updated version of SPICE called ngspice, which is relatively new (2014 release)
I'm fairly sure there are apps out there than have used either SPICE or ngspice, so I'm sure it can be done somehow.
I have read an article about a guy who says that ngspice has been compiled as a shared library(ctrl+f "ngspice"), and he made an app with it. I have emailed him but he unfortunately he has not responded.
The reason I am asking here is because when googling for "ngspice iOS", I came across this thread which has a lot of smart people trying to compile a static library, which seems way out of my scope. I learned that dynamic libraries are allowed as of iOS8. So would it be easier to compile a *.dylib than it is a static library?
How would I goabout using ngspice or SPICE in an iOS app?
Thanks
The difference between a static and a dynamic library is essentially where they live, a static library will live inside the binary of your app, and an dynamic library will live on the system (iPhone) that runs your app. there isn't much difference as far as difficulty goes. If you wanted to go the dynamic route on os x for example, you might compile a .dylib file in a separate project first. Then copy your new .dylib file into /usr/lib or a similar location that is part of your system's path. Then you would need to copy the associated header files that know how to talk to your new .dylib file into your /usr/include folder. At this point you could import said header files in xcode using angle brackets like so:
#import <my_dylib_header_file.h>
in static world however, you would simply drag your .dylib file into xcode then copy the associated header files into your source folder and then import using quotes like so:
#import "my_dylib_header_file.h"
the advantage of doing the import statically is that the library becomes baked into your final product, as opposed to a dynamic link, which will require that the dylib is installed on the system prior to the binary being able to run properly (think DLL's on windows). The disadvantage of a static import is that the final binary is larger, as it contains more code.
The advantage of a dynamic import is that the binary is smaller, and dylib can be updated without updating the binary itself.
However based on your questions I don't think any of this matters for your project. You have the source code. Which means creating a dylib is entirely unnecessary for your purpose, you can treat the source code like a static library by simply adding it to your xcode project. If I were you I would add the spice source code to my xcode project and forget about creating a dylib. From there I would import the files and make calls to them from swift. There are lots of threads out there that explain how call c functions or objective-c classes from swift so I wont go into that here, instead I'll refer you to another answer: Swift: How to call a C function loaded from a dylib
I know what is compile and runtime in Objective c, (method swizzling is a runtime) but I want to know what draws the line between these two library? one .a and .dylib ? What purpose do they serve, other than stating one is static and the other is dynamic? When would we need one over the other?
Static Library(.a)
Static libraries allow an application to load code into its address space at compile time.This results in a larger size on disk and slower launch times. Because the library's code is added directly to the linked target's binary, it means that to update any code in the library, the linked target would also have to be rebuilt.
Dynamic Library(.dylib)
Dynamic libraries allow an application to load code into its address space when it’s actually needed at run time. Because the code isn't statically linked into the executable binary, there are some benefits from loading at runtime. Mainly, the libraries can be updated with new features or bug-fixes without having to recompile and relink executable. In addition, being loaded at runtime means that individual code libraries can have their own initializers and clean up after their own tasks before being unloaded from memory
.a stands for Static library
.dylib stands for dynamic library
A Static library (.a)
A Static library (.a) is a pack of compiled classes, functions which can be used together with iOS app development project. It is a compiled binary or fat file and can be shared between projects.
You might want to create a static library for different reasons.
For example:
You want to bundle a number of classes that you and/or your colleagues in your team use regularly and share those easily around.
You want to be able to keep some common code centralized so you can easily add bugfixes or updates.
You’d like to share a library with a number of people, but not allow them to see your code. -
Dynamic Library
A file ending in the extension .dylib is a dynamic library: it's a library that's loaded at runtime instead of at compile time. If you're familiar with DLLs from Windows or DSOs, it's more or less the same type of thing with a few twists.
dylib are analogous to a windows *.dll file. They contain generic, unmodifiable code intended to be reused by many applications.
I need convert M4A files to MP3 and i guess this link is the answer : ios - convert .m4a to .mp3 file programmatically.
I was searching , how use LAME on iOS? and i find this :
https://gist.github.com/Superbil/7689556.
Once i execute, "build_ios.sh" 4 files are generated:
libmp3lame-armv7.a
libmp3lame-armv7s.a
libmp3lame-i686.a
libmp3lame.a
I understand the first two, are the libs that i need , for use this code :
ios - convert .m4a to .mp3 file programmatically.
How i can add this statics libraries to XCode and import for use the code?
I'm using the version 5.1.
Thanks in advance.
When using a static library, you need 2 things:
The static library itself (.a)
Header files to access its public interface
In the list of libraries you've posted, it would seem libmp3lame.a is the one you require. The three listed above it are for individual architectures, whereas the last one is a 'fat library', which is a collection of the individual architecture libraries. You can confirm this by running lipo on the fat library:
lipo -info libmp3lame.a
In order to incorporate it within your application, you need to:
Add the .a and header files to your project (with the application
being the intended target)
Add the library to the "Link binary with libraries" build phase,
found under 'Build Phases' for your target, within the Project
settings
Import/include the header files where you wish to use LAME
Ideally, it's worth having 2 sets of fat libraries; one for the simulator, and the other for the device. You can then include the appropriate one for the respective build target. This ensures the size of the application is the lowest it can be, but it's fairly harmless to include the simulator library within an App Store binary (it doesn't cause side effects).
Your question doesn't mention header files, and I don't see any reference within the build script as part of the build artefacts. You may need to copy the ones you require from the source itself into the project.
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