I am using Xcode 4 and LLVM 2 for a workspace which has two projects (A and B) in it. The main project (A) links against the binary of the other project (B) which builds a static library.
Project B contains categories so in order for it to link into A properly I set the ObjC and all_load linker flags. This however caused problems because some of our libraries that I use have symbols that should not be loaded so I tried to move over to using force_load specifically on the library file of project B.
-force_load $(TARGET_BUILD_DIR)/libB.a
This makes things work on the device however in the simulator the app crashes because categories from project B are not being linked in.
Any idea why force_load works differently on device and simulator?
Let me know if you need more details.
Try -Wl,-force_load,$(TARGET_BUILD_DIR)/libB.a; IIRC, it's a known issue that Apple LLVM Compiler 2.0 doesn't honor -force-load.
Related
Is it possible to have a single Xcode project (and ideally a single target) that will conditionally include frameworks when built against a certain version of OS X / Xcode but not include those frameworks when built against another version?
I'd like to begin adding support for El Capitan to an application I'm working on but some of the support I have in mind requires linking against frameworks that are not present in Yosemite. Is there a way to configure an Xcode project so that the same project can be built under 10.11 / Xcode 7 with the frameworks but also built under 10.10 / Xcode 6 without the frameworks (and without throwing an error)?
I'm aware of how to check for the existence of a class or method at runtime, but it's not clear to me how I control the framework linking without creating a second Xcode project, a second source control branch or always building against Xcode 7 (none of which I want to do, yet).
The "other version" would essentially be another target — it's setup this way to do precisely what you're asking about. A basic example would be just a matter of right-clicking on your original target and selecting duplicate from the current targets; then make whatever changes to linking frameworks within the Build Phases section.
Targets
In Build Phases you'll notice I've linked three frameworks to my
original target:
After right-clicking on the original target and creating a duplicate
I'm able to link it differently:
The duplicate version of MyApp uses the same classes and headers as the original with the exception of those that require the excluded frameworks. It's also possible to import different frameworks, change things such as the Deployment Target (e.g. build for different versions of OS X), or perhaps which SDK each might use, etc.
Once you're more familiar with the standard build process you can then create custom build scripts to handle specialized tasks like keeping the target names the same or even creating installer packages — anything is possible.
This question will be easy for Xcode pros but for a MonoTouch developer it seems to be impossible to resolve. :-)
I'm using Xcode 4.5 and I want to target iOS 5.1 and above and iOS Simulator 5.1 and above.
I have a a library project here and it is coming with a prebuilt binary named "DemoLib" (no extension and it is 11MB in size). The library is a fat lib for Simulator and iOS 5.1+.
I can use that library without any problem.
However if I try to build the library myself, I end up with a "DemoLib.a" file (notice the extension and the size of 30MB). How can I get the same build result? What is a .a file compared to the file without extension?
I tried to build the project "for running", and "for archiving" in Xcode. Both results in the same 30MB .a file.
I was expecting some dropdown in Xcode where one could select "DEBUG" or "RELEASE" build and the latter one would create the smaller lib.
Of course I could never tell without seeing the framework's project file. Having said that, there is an excellent guide to creating and compiling iOS frameworks here: https://github.com/jverkoey/iOS-Framework
Using the above guide, you should be able to recreate your framework's project from scratch, add the files you have to it, and properly compile it.
Hope this helps! :)
Did it come with a Makefile? Create a new target, set the build settings of the target to what's in the Makefile, then set your project to depend on that new target.
A file with the .a is a static library, which means it depends on nothing external and all the code it needs is compiled inside it. I think no extension generally implies dynamic library, which means it'll depend on some dependencies being present on your system to link against. Maybe that's why the .a is so much bigger. I think Xcode will build static by default because iOS does not allow the use of dynamic libraries.
The dropdown for what to build is in your scheme. Command+shift+< to view your scheme. Within the scheme you can edit which environment each method of building will use.
I recently did some research on making a cocos2d app for iPhone/iPad AND Mac. I have done the iPhone/iPad route but have never done it with a Mac target. It appears that some people have added it as a target but mentioned that it is finicky and others have suggested making a separate Cocos2d Mac project that uses the same files. Any wisdom to impart here?
I believe it is absolutely crucial to have both iOS and Mac targets in the same project. Otherwise you'll spend too much time keeping one platform in synch with the other, until eventually you either manage to create a good (but still time-consuming) workflow - or end up neglecting one of the two platforms.
Ideally the code base should make as little use as possible of compiler macros. You'll want to compile both iOS and Mac code even if it's not being used for one platform. So having some classes or methods that are #ifdef'ed to Mac, others to iOS, will more often than not lead to compile errors when you switch targets. That means wrapper classes, so that you can write the same code regardless of the platform, are essential.
Right now, Cocos2D doesn't offer you to create iOS & Mac targets in the same Xcode project. The way to get there isn't immediately obvious either, because each target requires its own build settings for: Base SDK, SDK Root, Deployment Target, Architectures and possibly Compiler version. It gets worse if you also want to use 3rd party libraries (Box2D, Chipmunk, etc) because in some cases you'll be forced to create iOS and Mac specific targets for those libraries as well - if only to ensure that the library is built with the same compiler as the project's target, otherwise you can run into the strangest build or runtime issues.
I've had issues getting these platform specific targets to work within a single Xcode project without Xcode complaining or otherwise misbehaving. I haven't tried it with Xcode 4.1 and 4.2. By that time I had created .xcconfig files to host the build settings. The .xcconfig files may or may not be necessary with the more recent Xcode versions but they definitely make managing multiple platform-specific targets easier.
Long story short, the best and easiest way to do cross-platform development with cocos2d-iphone is by using Kobold2D.
Most of the 15 template projects have an iOS and Mac target in each project, you just need to select the corresponding scheme, then hit build & run. The most commonly needed platform-specific code (processing user input) is wrapped in a platform-agnostic, simple to use wrapper class KKInput.
Disclaimer: I'm the developer of Kobold2D. There's a slim chance that I may be biased. You should try Kobold2D anyway. :)
I have an iPhone project that I want to use libcsoap in to make service calls. I'm having trouble linking a pure c library to xCode though. I've tried everything short of manually rebuilding the project as an Xcode project.
I built it via command line (./configure; make; make install). Then linked the output (libcsoap.a) and connected to the headers. This gave me a linker error saying that libcsoap.a was built for archiving and couldn't be used.
I tried creating a project out of just the makefile but that failed to build.
Can anybody explain to me what I should do to link these?
Thanks in advance,
George
If you create a static library for iOS do you have to distribute the header file(s) with it or is there another way to get it to work?
Currently I have a single my_lib.a file for both device and simulator but when I drag it into another test app to use it, it says it can't find the header and that all the places I'm using it in the code are undeclared. So I figure I'm either doing something wrong, or I have to also send the appropriate header files with it.
Background to my process:
I've seen two guides for creating a static library for both device and simulator. One on this site: Build fat static library (device + simulator) using Xcode and SDK 4+
and one here: http://mark.aufflick.com/blog/2010/11/19/making-a-fat-static-library-for-ios-device-and-simulator
I used the second site to just try it out. I'm also a bit curious if I did it correctly. I just went into the Release-iphone(os|simulator) folders and found the .a in the ios one and the .o in the simulator one.
The short answer is yes, you have to package header files with your static library. You have to package header files with any library in fact, dynamic or static. The library itself contains the compiled code, but you still have to tell the compiler about the identifiers in the library so when it's compiling your code it knows that they exist.
If you care, you can package your static library into a static framework with a little care. You simply create the same directory structure that a dynamic framework has, with your .a file in place of the .dylib (or .so) file. Frameworks contain a directory for headers, so you can distribute the binary and headers as a single package, and you can easily import headers from a framework without messing with the Additional Header Search Paths build setting.
Just in case it's useful - I followed Ray Wenderlich's instructions from here and was able to produce a framework for iOS that supported several architectures at once (including the simulator). The instructions are a bit too long to just copy-paste here.