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.
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 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.
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 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.
First, please forgive and point out if I am to use some other protocol for referencing another thread/post.
There was a previous thread how to compile spatialite for iOS where the top answer partly described building spatialite as a static library for iOS. The answer included the text:
"Once you've drag n drop the .a (both are required to work in the simulator AND on the real hardware), you can initialize spatialite by just invoking spatialite_init(1)."
I am guessing this is translated to some version of the following?
Xcode 4
File->New->New Target->iOS->Framework & Library->Cocoa Touch Static Library
Name the library - libSpatialite_TedS
Drag the header files to libSpatialite_TedS -> Copy Headers (question here ... there is a spatialite.h file in the 'headers' directory of the 'spatialite2.3.1.zip' download. Then in the subdirectory 'spatialite' there is another spatialite.h that is not an identical file and is obviously needed. Do we just drag the header files from 'headers' directory, then drag the directory 'spatialite' as a directory into 'Copy Headers' area of our Xcode static library 'myNewLibrary'?)
Drag the '.a files' libSPATIALITE2.3.1_arm.a & libSPATIALITE2.3.1_x86.a
Shouldn't we have some '.m' files to go with these headers in the 'Compile Sources' field?
Now, without referencing the libSpatialite_TedS in my project, when I 'Command-B' to build, the project build succeeds. However, when I look for the compiled product in
/Users/Admin/Library/Developer/Xcode/DerivedData/MyProject-gutnkbwqqonzgxbcmfzzzkadqhid/Build/Products/Release-iphonesimulator
I see build's products, but they do not include libSpatialite_TedS.
Is this because the compiler is 'smart' and recognizes that none of the header/.a files are referenced in the project so it does not bother compiling them?
And, is this the correct way to go about achieving the objective of the original poster how to compile spatialite for iOS?
Many thanks,
Ted S
I was running into linker errors with the original poster too, but solved it by including libsqlite3.dylib, libstc++.dylib, and libiconv.dylib in the target.
Hope this helps!
Ted, I believe that the .a (static library) files and headers are meant to be used in a project right away, rather than in another static library as you've described. They are the result of a project's output. I think you can find the project that built them, here:
http://lionel.gueganton.free.fr/spatialite/
And a little more on static library files:
What is a .a (as libcrypto.a) file?
EDITED
Here's another link that you might find helpful. It s a summary of the Static Library build process in iOS:
http://www.icodeblog.com/2011/04/07/creating-static-libraries-for-ios/