I'm trying to make a library and want to copy the header file to the dylib, but when I put libAC.h in libAC_FILES, I get this error when I compile
*** No rule to make target `obj/libAC.h.f3cc93fd.o', needed by `obj/libAC.dylib.ba964c90.unsigned'. Stop.
I want it to be that when I make a different application, I can do #include <libAC.h> and use the methods from that library, but I can't find any examples on how to do this. This is for a jailbroken device, by the way. I'm using the library template in theos, and using make package install to make the library and install it to my phone, if it helps.
What im trying to do is install the header file for my dylib to /usr/include
Headers are not supposed to get bundled into a library binary. A dylib is a shared library that is binary only.
A dylib is not the same thing as a framework (which is a bundle of a library and its headers) - I guess that is where your confusion comes from.
For allowing you to include the headers needed for using functions of your library, you will need to put those into the header-search-path of your compiler. You may certainly also extend that path towards any folder that contains your header/s.
Since you are using some packaging script as it seems, check with the documentation of that script (or simply analyse it).
And as a final note, do not use the sharp brackets (<, >) for delimiting custom header includes. Only system headers are supposed to get those. Use standard quote marks instead (").
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 have code for a VST plugin and need to port some of it to an iOS app.
I have tried building the OSX version and using the lib.a and it doesnt work. When I open the iOS version of it, Xcode shows that it is missing the tagret.
If I copy the code directly into Xcode with all the JUCE modules, and I set the header search paths, I get compilation errors on things like no such type for String
After this latest JUCE update, Xcode would give the same errors until I updated the JUCE file itself, so I think the JUCE build settings or configuration of the new version is doing something differently. How can I get this code into a different Xcode project, so that I can use it?
Can I compile it as a library and use the objects through the header?
JUCE is designed to be included in projects generated by the Introjucer / Projucer (the JUCE project management tool). Without this, the correct preprocessor definitions will not be set up.
If you really needed to include JUCE source code inside your program, you could manually set up these preprocessor definitions (take a look at the AppConfig.h header from a generated project to get an idea of how much work this will be), but you'd really be going against the normal "JUCE way".
Simply including the headers and linking against the library will not work without considerable effort, as the include structure is ... odd ... and there isn't any library to link against directly anyway (the generated projects contain all the JUCE source normally, so there's no need).
Adding the JUCE source files (i.e. .cpp and .mm) to be compiled in a project directly will result in compilation errors, as they need to be compiled in a very specific order which is mandated by the header file (the header files #include certain implementation files after setting up their dependencies).
In short, if you can at all I would advise generating the project with the Projucer and adding other source files in as you need them, rather than the other way around.
TL;DR
How do I build a static library without including a third party library that I'm referencing?
Hi,
Before I begin, I know how to compile a static library in Xcode targeted for iOS devices and simulators. However, this time around I have a dependency on a third party library that I do not want to include in the static library. I simply want to reference it. However, whenever I am building my static library I get a lexical or preprocessor error, which I know is common when the library is missing from the project. The error occurs because I removed the library from the project, because I didn't want to have it built into the static library.
The library in question is AFNetworking. I will be using CocoaPods to explicitly have the dependency installed when installing my static library.
Thank you.
When you reference external code, you will always need to have the headers accessible by your project, otherwise the compiler wouldn’t be able to tell you if you are referencing the external code in a proper manner. E.g. does the method exist, are you providing the right types, etc.
The duplicate symbol problem only exists when you actually define a symbol multiple times. For instance, defining class related Objective-C symbols only happens in a #implementation...#end block, not in a #interface...#end block. The latter is only for the compiler to make sense of things.
(This is also why you can define a #interface for e.g. a private class and use it as normal and not cause duplicate symbols.)
Therefore, you can include such ‘clean’ headers multiple times without having to worry about it. Note that I said ‘clean’, because you can actually define symbols in headers by, for instance, defining C functions in headers or even a Objective-C #implementation, if you feel especially wicked. But you will simply have to test this.
The linker will complain when you finally link the 3rd-party dependency and yours and there were duplicate symbols after all. In that case, be sure to look into tools such as nm which list the symbols in an archive.
you can add the lib.a and lib.h into your project.
I'm building an iOS static library (as per https://github.com/jverkoey/iOS-Framework). I depend on SBJson and AFNetworking. I would like to include these libraries to avoid version issues and for installation simplicity; to do so, I need to prefix these libraries to avoid naming conflicts.
How can I prefix other static libraries in a simple way?
Ideally, it would be part of my build process. Less ideally, but acceptable, are tips on how to refactor and rename in a sane manner.
The only safe solution (other than not doing this at all) is to build any dependencies with a prefix on all symbols.
The easiest method of prefixing is the classic "find-and-replace". This is error-prone, so it's a good idea to hit the .a with nm -a and scour the results for any non-prefixed symbols.
A second, much safer method is to use a two-pass compilation process.
The first pass builds the dependent project and runs nm to dump all symbols into a header file.
The second pass builds the dependent project again, but this time with the generated prefix header file imported in the precompiled header. This prefix header must be used anywhere you reference symbols from the dependency in your framework in order to properly refer to the renamed symbols.
For reference, we use this with Nimbus to generate the Nimbus prefix headers:
https://github.com/jverkoey/nimbus/blob/master/scripts/generate_namespace_header
This allows you to distribute a .framework with a prefixed version of Nimbus embedded.
You can now link the resulting .a into your framework and safely avoid any linker conflicts when a third party developer inevitably links their own version of the dependency into their project.
I am using RestKit, GData and Facebook API.
All of them has a JSON files, many of them share the same name, enums etc.
When i compile I get an error on duplicates.
How can i prevent the conflicts?
Thanks
Shani
This is my best guess. It would be helpful to post the errors you get on compile.
If you are using the -all_load linker flag, turn it off. If your libraries require that you use this option, try using -force_load option on the specific libraries that require it. As an absolute last resort, build the libraries that you can from source, renaming colliding symbols.
The question below might provide some more insight on the all_load issues:
Objective-C categories in static library
I ran into this issue because the new Facebook SDK 3.0 is now a static framework which also includes SBJSON, I also have another static framework which also includes the same class. Originally I would just go in and edit the source files of the Facebook SDK and apply a custom prefix to the SBJSON classes. This no longer works.
Here is an outside the box solution.
Navigate to FacebookSDK.framework->Versions->Current
Open the compiled FacebookSDK library file with the best IDE, textedit will do!
Search case sensitive and replace all occurrences of "SBJson" with "FBJson"
Search case sensitive and replace all occurrences of "SBJSON" with "FBJSON"
Save, clean, compile.
Note: Some would say, why replace with FBJson and not FBSBJson? I determined it would be best to keep it the same character length to be safe.
Note: If you are attempting this with other frameworks, be sure to search the header files for any references to the conflicting class that you are renaming. In this case the class being renamed was not referenced in any of the header files. If it had been, I would have made sure to rename it in the header files.