I'm working on few plugins for Quartz Composer, that all link to the same custom static library copied for each of them in the bundles frameworks folder. The plugins could be used separately, so I have to distribute the library in each plugin.
Everything goes well, apart from the isMemberOfClass and isKindOfClass methods. I read here that importing twice the same classes could be the origin of the problem.
I have no error at compilation.
Let's say that I have 2 plugins (NSBundles) that contains the lib XCode project and compile it before linking to it.
They both copy the lib in their resources folder.
Then, they both instantiate a custom hOzPolygon2D class from that library.
The first plugin return true to the test of the hOzPolygon2D object with isMemberOfClass method.
The second return false.
isKindOfCLass method returns the same "error".
I can't imagine a solution in my case. I'm really not a compilation professional and would really appreciate some help.
You should distribute the static library separately (possibly as its own framework). From the question title I assume you're seeing duplicate symbol errors from the linker. If you statically link the same static library into multiple other libraries and then try to link an application to more than one of those libraries you're bound to see these duplicate symbol issues. I haven't actually tried this with frameworks, but I know of this issue from linking iOS apps against interdependent static libraries.
You shouldn't worry about the fact that the modules can be used separately. Just make sure your users can also get the base library. This is a normal situation. For example AppKit and UIKit depend on Foundation, but neither of them actually contains a copy of Foundation.
Related
In our Xcode project we have multiple targets which share some common code. Each target includes only sources which are actually used by it. So when we use some category methods inside classes which are shared between targets we need to make sure that this category implementation is also included in all targets. Xcode doesn't show any warnings during compile time or link time if we forget to include category implementation to some of the targets. And it is troublesome to do it by hand.
Is there any automated way to ensure that category implementations are included to the targets which use them?
Categories are not automatically linked to the final binary.
They are linked if the linker finds the file where they are defined is used (which was a source of constant bug some times ago).
What you can do is use a special flag on the linker: '-all_load' and '-ObjC' in Build Settings/Linking/Other Linker flags
-ObjC Loads all members of static archive libraries that implement an Objective-C class or category.
And from this discussion:
-all_load and -force_load tell the linker to link the entire static archive in the final executable, even if the linker thinks that parts
of the archive are unused.
Another way I use to force link the module is to put a C function in the file:
void _linkWithNBLogClass(void)
{
NSLog(#"%s", __FUNCTION__);
}
and call it at the start of my application:
linkWithNBLogClass();
This way, by the console feedback, I'm sure my module is loaded and ready to be used.
The described behavior is as intended and much existing code would break, if it is changed.
Prior to formal protocols there was a need to declare methods without defining them. This was for optional methods, i. e. for declaring a delegate API. The usual technique was to declare a so-called informal protocol, consisting of a category on NSObject that is never implemented.
But if you have a category implementation, of course the completeness of it is checked against the category interface. (Otherwise you get a "Method definition for X is not found" error.) So you do not have a missing method in the category implementation, but a missing category implementation.
I do not think that this is a big deal. You will get a runtime error instead of a compile time error and simply add the category implementation to the target.
I have a scenario where I need to use a plugin as well as a static library into my xcode project. The plugin will be dynamically loaded into the system. Now, the static library is also getting used in creation of the plugin.
While executing my project I am getting a warning saying :
Class A is getting referenced from /staticLibraryPath and plugin. One of them will be used.
Please let me know, how to resolve the warning or a better way of implementing the scenario.
The issue is a name class of the two ClassA types found in both plugin and library
I assume you have control over the source of either plugin / library.
.. rename Class A in one instance to make the names not clash -- I don't think there is another way to get rid of the warning/error
I try to put some reusable functions into my own static library but i noticed one problem.
Let's say the static library has many functions and some requires quartz core framework, some requires messgeUI etc.
When I build a new project, I include this static library project into my code so that I can reuse those functions.
Now even if I only use a simple function that doesn't require any frameworks, I am forced to include all the quartzcore, message UI frameworks or I will face build errors because the static library requires them- but I do not need all of them!
How can I design a better general purpose static library that doesn't force people to include frameworks that is not used by them at all?
You can use weak linking - if weak linkage is used, unused symbols (functions, methods, global variables) don't have to be present at linking time.
I am looking at this page about C++ differences from Objective C and it states this:
The dynamic nature of Objective C allows existing classes to be extended at runtime. Objective C allows you to define categories, related sets of extensions to objects you've already created. For example, in converting a text-based app into a graphics app, the code your objects needed to draw themselves could be compiled as a category and loaded at run-time only when needed. This saves memory and allows you to leave your original objects unmodified.
Now I am familiar with Categories and have used them, but I do not see how they lead to dynamic loading. If you import a Category file, is it not compiled along with the class it extends, taking up memory whenever you use that class, whether you use the Category methods or not?
You can load a bundle/plugin/framework at runtime. This is the dynamic nature of Objective-c that the quote references. It is not specific to Categories.
However, if the (compiled) code you load includes a Category on an existing Class, the extensions will work just as if they had been there all along. Ie a Class is not 'Frozen' at compile time, and loading a bundle/plugin/framework is one way to add new methods to an existing class at runtime.
This makes it relatively easy to implement a plugin architecture, or load code only when needed to make app startup time faster/keep memory footprint down, compared to some other C based compiled languages.
If you link with a static library containing a category, the linker will copy all of the category code into your executable file. If you link with a shared library, the shared library's entire code segment gets mapped into your process's address space, but it's paged in lazily, so you might not actually read all of the category code off of the disk unless you use it all.
But I think that's not really what the page is talking about.
Link-time libraries
First, let's talk about libraries that you tell the linker to link your app with.
Consider NSString. The NSString class is defined in the Foundation framework, which is a framework full of general-purpose classes useful in programs that have GUIs and in programs that don't have GUIs. So the NSString class as defined in Foundation doesn't include any code for drawing a string into a graphics context, because that code would (usually) be useless in a non-GUI app.
The AppKit framework (on OS X) manages a GUI. It's useful in a GUI to be able to draw strings to a graphics context, so AppKit contains a category on NSString that adds methods for drawing a string, like drawAtPoint:withAttributes:. UIKit (on iOS) does the same thing (but the methods are a little bit different).
So if you write a program on the OS X and use Foundation but don't use AppKit, your process won't load the AppKit NSString category and you won't pay the price for all of those graphics methods on NSString.
For a shared library like AppKit, the price is pretty trivial on modern hardware.
Now, you could do the same thing with your own libraries, which you might make static. Let's say you make a “TwitterModel” library for talking to Twitter. It's full of classes that model the things you find on Twitter, like accounts and tweets. But you don't include code for managing a GUI to display tweets.
Instead, you make another library, “TwitterGUI”, that (in addition to defining yet more classes) uses categories to add methods to the model classes in your “TwitterModel” library.
If you write a program that links to both TwitterGUI and TwitterModel, the executable file will contain all of the Objective-C code from both libraries. But if you write a command-line only program (no GUI) and only link it with TwitterModel, that program won't contain any of the GUI-related code. Oh, the savings!
Run-time libraries
Now let's consider shared libraries that you don't tell the linker to link your app with.
You can dynamically load new code into your process at runtime, using an API like dlopen or -[NSBundle load]. If the library contains categories, those categories will be added to the classes in your running program.
So, you could make your app optionally use a shared library if it exists on the user's system when he runs your app, by trying to load the library programmatically. If you succeed, you can call any category methods that you know the library defines. (And of course you can use the classes that the library provides, if any.) If you fail to load the library, you carefully avoid calling any of those category methods from the library.
Typically, though, we use a dynamic loading API to load a plugin, and the plugin provides some class that subclasses a base class, or conforms to a protocol, that we've defined specifically for plugins to implement. We just need to get the name of that class, and then we create an instance of it and send it the messages that we defined in our base class or protocol.
I'm trying to find the best way to package a static library(lets call it Lib1) that includes an optional class(say, ClassA), which itself requires a second static library(Lib2). In other words, Lib2 is only needed if ClassA is referenced in the project's code. Things seem to work fine, unless Lib1 is used in a project that doesn't use ClassA(and hence does not include Lib2), but requires the -ObjC linker flag(because of other project dependencies, not mine).
I'm trying to come up with a an easy solution for the following three scenarios:
1) project includes my static lib, does NOT use the optional class, does not specify the -ObjC flag
2) project includes my static lib, does NOT use the optional class, but requires -ObjC flag
3) project includes my static lib + second static library, and DOES use the optional class (we don't care about the -ObjC flag at this point)
Is there a linker flag out there to strip my optional class out of the final project app so that it doesn't require the second static lib? I guess my other alternatives are to release multiple versions of my static lib, one that includes the option class(the standard choice), one that does not(the alternate, for projects with -ObjC requirements), or maybe supply a stub file, that supplies empty implementations of all the classes needed from the second static library? This seems like it could be a common problem in the static library world... is there a best practice for this scenario?
Thanks!
Solution:
1) Suggest to my -ObjC users that they use -force_load instead. (thanks Rob!)
2) For users that can't do 1, I'll have a alternate build that does not include ClassA
The best practice is always to have the final binary link all the static libs required. You should never bundle one static library into another. You should absolutely never bundle a well-known (i.e. open-source) static library into a static library you ship. This can create incredible headaches for the final consumer because they can wind up with multiple versions of the same code. Tracking down the bugs that can come from this is insanely difficult. If they're lucky, they'll just get confusing compiler errors. If they're unlucky, their code will behave in unpredictable ways and randomly crash.
Ship all the static libraries separately. Tell your clients which ones they need to link for various configurations. Trying to avoid this just makes their lives difficult.
Some other discussions that may be useful:
Duplicate Symbol Error: SBJsonParser.o? (Example of a customer who ran into a vendor doing this to him)
Linking static libraries, that share another static library
Why don't iOS framework dependencies need to be explicitly linked to a static library project or framework project when they do for an app project?
The -ObjC flag should be preventing the automatic stripping of ClassA entirely, whether its used or not (see TN1490 for more details).
If ClassA is never used except in certain circumstances and you want to save space, you should probably move ClassA into its own static library. Or use #ifdef to conditionally compile it.
Alternately, you can remove the -ObjC flag and use -force_load to individually load any category-only compile units (which is the problem -ObjC is used to address).