I'm working with the Vuforia library for iOS (augmented reality). The library framework is only compiled for armv7 and v7s arch - thus it won't run in the simulator (i386 arch). In order to test the rest of my app in the simulator I've wrapped parts of my code that reference the vuforia functions in compiler macros as such:
#if TARGET_IPHONE_SIMULATOR
//do simulator stuff
#else
//do vuforia stuff
#endif
This has taken my error count down to just one left - which I can't seem to get rid of:
Undefined symbols for architecture i386:
"QCAR::Renderer::getInstance()", referenced from:
SampleMath::projectScreenPointToPlane...
I have found SampleMath.cpp and have found the one and only call to reference to renderer.getInstance and have wrapped that in the macros. I've tried wrapping the entire .h and .cpp file in the macros; I've searched my entire xcode project for other places where the code might be referenced. Still after multiple cleans, and a OS X + xcode restart; still getting the same compiler error. Any Ideas? If so - many thanks.
It seems that Xcode doesn't define automatically TARGET_IPHONE_SIMULATOR in .cpp files.
The solution is to insert at the begining of your .cpp file :
#include "TargetConditionals.h"
Then all tests on TARGET_IPHONE_SIMULATOR will work.
Related
I'm using the Crashlytics CLS_LOG macro throughout my project. It's working everywhere except in one class, where I get Implicit declaration of function 'CLS_LOG' is invalid in C99. If I comment out the calls in that one class then the entire project compiles fine.
I'm including Crashlytics in my prefix.pch like this:
#ifdef __OBJC__
// Other imports
#import "Crashlytics/Crashlytics.h"
// Other imports
#endif
I've trying clearing pre-compiled headers, reinstalling the Crashlytics framework, and more - nothing has helped.
Any idea what could be breaking the macro in a single class?
I figured it out.
The problem was that I had added this class to the compiled sources for a new target (a widget), but I hadn't added the Crashlytics framework to that target.
I also followed the instructions from this answer to create a prefix.pch for the widget target, added Crashlytics to that, and now everything is compiling as expected.
I am trying to add iRate from https://github.com/nicklockwood/iRate to my app.
After adding file i get this error before even running the project.
#import "iRate.h"
#import <Availability.h>
#if !__has_feature(objc_arc)
#error This class requires automatic reference counting
#endif
http://i.stack.imgur.com/amxPM.png
The solution in this issue in this link https://github.com/nicklockwood/iRate. It is for ARC Compatibility.
As of version 1.7, iRate requires ARC. If you wish to use iRate in a non-ARC project, just add the -fobjc-arc compiler flag to the iRate.m class. To do this, go to the Build Phases tab in your target settings, open the Compile Sources group, double-click iRate.m in the list and type -fobjc-arc into the popover.
If you wish to convert your whole project to ARC, comment out the
#error line in iRate.m, then run the Edit > Refactor > Convert to Objective-C ARC... tool in Xcode and make sure all files that you wish to use ARC for (including iRate.m) are checked.
I tried using the Glew Library for shading and was trying to compile a simple program using the NSOpenGLView Class in Xcode 5. The program fails at the following code in glew.h
#if defined(__gltypes_h_)
#error gltypes.h included before glew.h
#endif
It says that Gltypes.h is included before glew.h.
My implementation file for OpenGLView has headers included in following fashion:
#include <glew.h>
#import "OpenGLView.h" // Includes Cocoa.h
#include "LoadShaders.h" // Includes <OpenGL/gl.h>
So, if glew.h is included in the beginning, why is the error coming here. None of the other headers are included before the inclusion of glew.h, so tests for them(like gl.h) are passing in glew.h. I am not able to find out here as to who is including Gltypes.h in this file.
Hope anyone has a clue to it here.
The precompiled header file (.pch) pulls Cocoa in. Edit it to include glew.h before Cocoa.h and you are good to go.
Code:
struct IRenderingEngine {
virtual void Initialize(int width, int height) = 0;
virtual void Render() const = 0;
virtual void UpdateAnimation(float timeStep) = 0;
virtual void OnRotate(DeviceOrientation newOrientation) = 0;
virtual ~IRenderingEngine() {}
};
Learning opengles from a book for 3d iphone programming and it uses this example code but the book is targeted for xcode 3.x
Somehow I feel like its something with xcode 4....
EDIT:
Heres the actual error:
/Users/Dan/Documents/opengles/Hello Arrow/Hello Arrow/IRenderingEngine.hpp:27:2: error: unknown type name 'virtual' [1]
And that legitamtely is all that it takes to fail to compile, absolutely no other files. (Yes I've tried compiling with literally a main.m and this hpp file)
It is recognizing the hpp file as a cpp header file though, if I try to add it to the compiled files it says that "no rule to process file '$(PROJECT_DIR)/Hello Arrow/IRenderingEngine.hpp' of type sourcecode.cpp.h for architecture i386" so I really have no idea what is going on
Note that I compiled with main.m meaning I compiled another Cocoa/Foundation based application
I tried compiling for a c++ application and everything worked out just fine....
Similarly compiling with a main.mm test file worked fine too
heres the actual project, lemme know how insane I really am:
[Removed considering I lost the file]
Please rename the main.m to main.mm. This worked for me.
If you're using Xcode 4, try changing the name of file "AppDelegate.m" to "AppDelegate.mm". It works for me.
Changing the name of file "AppDelegate.m" to "AppDelegate.mm". It's correct!
I moved the #import "IRenderingEngine.hpp" line from the GLView.h file to the GLView.mm - this prevented it from being imported into the main.m and HelloArrowAppDelegate.m files when they were compiled - and restricted the import into the .mm file, that could handle the C++.
I also had to make a couple of other fixes for bugs I'd introduced when typing in the code - so apologies if that wasn't the only thing that needed to be done, but it might help those with similar problems!
if you call C++ files ( even if you only import them ) you need to change the .m file that call's it to .mm
This is just a stupid guess since I've never tried compiling something with the word virtual in a C compiler... but is there any chance that you were trying to compile this C++ code as C code? That's the only reason I can think of that a compiler wouldn't understand the keyword virtual.
The header <stdlib.h> is not the right one to use in a C++ program. When I replaced it with the c++ version of C's stdio library <cstdlib> then your code compiled for me.
openFrameworks and cocos2d both have a wrapper for EAGLview.h, and of course you can't just use both. Just adding both libraries (libcocos2d.a and libofxiPhone_iphoneos_Release.a) to my project gives a linker error:
ld: duplicate symbol _OBJC_METACLASS_$_ES1Renderer in /Developer/of_007_iphone/apps/cwi007/iTicTacToe/libofxiPhone_iphoneos_Release.a(ES1Renderer.o) and /Developer/of_007_iphone/apps/cwi007/iTicTacToe/libs/libcocos2d.a(ES1Renderer.o) for architecture armv7
collect2: ld returned 1 exit status
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 failed with exit code 1
I'm writing the core of my program in openFrameworks because it's easy and C++. I want to put a UI, transitions, menus etc. in with cocos2d because it's also easy and looks nice.
I tried
#define __OPENFRAMEWORKS__
in one .h file, and wrapping the other in
#ifndef __OPENFRAMEWORKS__
#endif
figuring I could "augment" the .h in openFrameworks with the extra bits added in by cocos2d, but then openFrameworks wouldn't build because it no longer had a definition for EAGLview.
Is there a best practice for working with two libraries like this that both tap into the same low-level functionality, in this case CoreAnimation? Can I write my own class that inherits from them both? Is there a way to excise one of the .h files from my project?
Try to include the cocos2d.h header where EAGLview.h is included in the original openFrameworks code (i.e. ofMain.h), or vice versa.