Open GoogleCodeExporter opened 9 years ago
[deleted comment]
Hmm,..what cmake-version do you use? Seems that this platform-stuff was
introduced in 2.8.6. The problem wiht iOS at the moment is that noone of the
active commiters do have an iOS-system, so it is really hard to maintain this.
Nevertheless I found this:
http://cmake.3232098.n2.nabble.com/Specifying-library-build-path-for-simulator-a
nd-device-for-an-iOS-target-in-Xcode-td6985862.html
Can you try to add:
set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "-iphoneos;-iphonesimulator")
in following files:
[gamekit]/CMake/ConfigOgreKit.cmake Line 158
[gamekit]/CMake/ConfigIPhone.cmake Line 7
And:
config_target_if_iphone_build(fbtFile TRUE)
in:
[gamekit]/Tools/FileTools/File/CMakeLists.txt last line
And:
config_target_if_iphone_build(bfBlend TRUE)
In:
[gamekit]/Tools/FileTools/FileFormats/Blend/CMakeLists.txt last line
I couldn't test this, so I keep my fingers crossed. Would be great if you could
test this and report back.
Thx for reporting
Original comment by thomas.t...@googlemail.com
on 25 Jul 2012 at 10:21
Original comment by thomas.t...@googlemail.com
on 25 Jul 2012 at 10:21
Ok, i commited a patch that should fix the issue. Plz, get the latest trunk
version and try again.
http://code.google.com/p/gamekit/source/detail?r=1120
ps: just saw that in the commit-description I have a typo in your username.
Argh, sry about that.
Original comment by thomas.t...@googlemail.com
on 25 Jul 2012 at 6:03
Sorry I haven't got a chance to try anything until now. The new commit works!
Thank Thomas for the prompt fix.
I use cmake 2.8.8.
All the iOS/OSX users reading this: we really should donate some money (maybe
$20 each) to buy a mac for our main committers. Otherwise, this platform won't
be so well supported. It's a little surprising not to see a lot active iOS
developers to use gamekit (as opposed to android developers), who can also
contribute to gamekit, given the iPad/iPhone's popularity. I got this
impression after browsing gamekit.org. Maybe I'm wrong. I just got started to
learn gamekit.
Original comment by afterb...@gmail.com
on 26 Jul 2012 at 5:36
The new build worked for iphone simulator, but when I build for an actual
iphone, there is another error:
#error The C preprocessor macro ARM_NEON_GCC_COMPATIBILITY must be defined.
Pass -DARM_NEON_GCC_COMPATIBILITY=1 to the compiler.
I don't know if this can also be fixed in cmake files. In fact, I don't even
know how to fix this inside the xcode project myself. At least I'm running out
of time today for this. Any clues are very much appreciated.
Original comment by afterb...@gmail.com
on 26 Jul 2012 at 7:54
[deleted comment]
Hmm... again without testing:
go to gamekit/CMake/ConfigIPhone.cmake line4:
add_definitions(-DARM_NEON_GCC_COMPATIBILITY=1)
this should add the compile-flag to any lib that gets compiled in the iPhone
project. Or lets say it different, any lib that calls
"config_target_if_iphone_build(..)" in its CMakeLists.txt (you know the one
call that missed for bfBlend and file)
Hopefully it works...
Original comment by thomas.t...@googlemail.com
on 26 Jul 2012 at 9:25
Hmm,..ok that is something bullet-related. Maybe erwin can help here out. The
problem happens in btScalar.h line 177. Actually I'm not sure when to set
ARM_NEON_GCC_COMPATIBILITY to 0 and when to 1.
Original comment by thomas.t...@googlemail.com
on 26 Jul 2012 at 11:53
I was able to kind of overcome this ARM_NEON_GCC_COMPATIBILITY issue. But not
in a sufficent way. But I managed to compile it, by manually adding the
-DARM_NEON_GCC_COMPATIBILITY=1 to the other c++ flags. This works, but only
when the architecture is set to only support armv7. Apparently armv7 has NEON
enabled by default and thus it works. armv6 does not and I did not yet find out
how to enable it.
Original comment by underd...@gmail.com
on 26 Jul 2012 at 3:20
Ok, since bullet is an external library with its own CMake-Files it won't be
accessed by ConfigIPhone.cmake. So add_definitions(...) would have to be set in
LinearMath's CMakelists.txt. But actually I'm not sure if that flag is meant to
be set externaly. I haven't that much time to dig deeper into that for now
Original comment by thomas.t...@googlemail.com
on 26 Jul 2012 at 3:41
Why do you want/need to build for iOS armv6?
Original comment by erwin.coumans
on 26 Jul 2012 at 4:16
@erwin: So would adding:
if (OGREKIT_BUILD_IPHONE)
add_definitions(-DARM_NEON_GCC_COMPATIBILITY=1)
endif()
to bullet/CMakeList.txt sufficient and can we assume this is true for every
iOS-device? Or do we have to differ there?
Original comment by thomas.t...@googlemail.com
on 26 Jul 2012 at 5:35
I played some more with xcode settings. Following the tip from "underd...", I
could get the project to build for an iphone after adding that flag to the
Other C++ Flags in xcode for the following 4 targets: LinearMath,
BulletCollision, BulletDynamics, OgreKitCore and IPhoneDemo. Make them 5
actually :). We need to do this for each build configuration. So far I only
tried Debug.
I only tried armv7 (that's the only option I have in my xcode). Here is the
introduction to the NEON technology
(http://wanderingcoder.net/2010/06/02/intro-neon/). Seems that armv6 is not
compatible with this flag anyway.
A fundamental fix of the xcode project will be very nice.
Original comment by afterb...@gmail.com
on 27 Jul 2012 at 7:07
@erwin.co... Usually I try to build things in a way that they work for as many
older devices as possible. But I don't know whether there are still armv6
iphones around?
Original comment by underd...@gmail.com
on 27 Jul 2012 at 11:44
Anyone of you two iPhone-guys did try what I mentioned in comment 13?
Original comment by thomas.t...@googlemail.com
on 27 Jul 2012 at 12:25
Not yet, I can try tomorrow if I get to my desktop computer
Original comment by underd...@gmail.com
on 27 Jul 2012 at 12:48
[deleted comment]
Thomas, I tried Comment 13 but it's not enough. I still got the same error when
building OgreKitCore. As I mentioned in my last post, 5 targets are affected.
Comment 13 should only fix the first 3 of them. It should be straightforward to
fix the rest 2 in a similar fashion. But as you asked before, I was also
wondering if this is the proper fix by adding the flag to the cmake files.
Original comment by afterb...@gmail.com
on 28 Jul 2012 at 6:33
Actually it is strange. The flag seems not to be not(?) used in the code at
all. Setting
#define ARM_NEON_GCC_COMPATIBILITY 1
before the if-statement actually make it compile (which is of course no
solution)...
"comment 13" seems to have no affect at all!? At least when I compiled....not
sure if cmake was updated properly.
Well, but you can see the buggy (argh) iPhone-multitouch demo. (Seems to me
that iPhone still have some real issues, especially input-control)
Original comment by tomag...@googlemail.com
on 28 Jul 2012 at 9:27
It looks like comment 13 worked for me.
I added
IF(OGREKIT_BUILD_IPHONE)
add_definitions(-DARM_NEON_GCC_COMPATIBILITY=1)
ENDIF()
to bullet/CMakeLists.txt and CMake/ConfigGameKit.cmake
But I still need to disable armv6 manually
Original comment by underd...@gmail.com
on 30 Jul 2012 at 11:04
but I still get one linker error:
Undefined symbols for architecture armv7:
"_objc_copyCppObjectAtomic", referenced from:
-[EAGLView mWindowName] in libRenderSystem_GLESStatic.a(OgreEAGLView.o)
-[EAGLView setMWindowName:] in libRenderSystem_GLESStatic.a(OgreEAGLView.o)
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Original comment by underd...@gmail.com
on 30 Jul 2012 at 12:47
ok. I found a solution to this linker error message. Apparently the ogre
EAGLView doesn't compile properly in XCode 4.4. So I downloaded the ogre trunk
and checked if the error was fixed in there and it is. I had to change line
number 44 from
@property (assign) String mWindowName;
to
@property (nonatomic, assign) String mWindowName;
I used the newest svn version (r1162). Thanks for already including
add_definitions(-DARM_NEON_GCC_COMPATIBILITY=1) for all the bt* targets. But I
had to set those definitions for the OgreKitCore and iPhoneDemo targets as well.
Original comment by underd...@gmail.com
on 7 Aug 2012 at 11:45
Ok, even though I only got a warning where you got an error. I commited your
fix, and also added the ARM_NEON_... to the uppest CMakeLists.txt which worked
for me...
Hope that works now. Just a matter or seconds until the next iOS-issue :D
http://code.google.com/p/gamekit/source/detail?r=1163
Original comment by thomas.t...@googlemail.com
on 7 Aug 2012 at 9:29
I just noticed something else. To successfully build glres2 ogre render on for
ios, I had to change the following block to
http://code.google.com/p/gamekit/source/browse/trunk/Ogre-1.8rc/CMakeLists.txt#1
64
if (APPLE)
if (OGRE_BUILD_PLATFORM_IPHONE)
include_directories(${OGRELITE_SOURCE_DIR}/OgreMain/include/iPhone)
include_directories(${OGRELITE_SOURCE_DIR}/OgreMain/include/OSX)
else ()
include_directories(${OGRELITE_SOURCE_DIR}/OgreMain/include/OSX)
endif()
endif()
Original comment by underd...@gmail.com
on 21 Aug 2012 at 6:12
Great, will add this immediately
Original comment by thomas.t...@googlemail.com
on 22 Aug 2012 at 12:22
The latest version of Bullet trunk shouldn't need the
ARM_NEON_GCC_COMPATIBILITY definition anymore.
Please remove it again from cmake/any build system.
Original comment by erwin.coumans
on 31 Aug 2012 at 10:53
I also noticed that in Xcode, the IPhoneDemo target was set to depend on most
of other components such as OgreMain, but the dependencies list misses the
following components: BulletCollison, BulletDynamics, LinearMath,
RenderSystem_GLES, and Plugin_ParticleFX. This can be seen from the Build Phase
page for IPhoneDemo.
This doesn't seem correct to me, as IPhoneDemo obviously depends on those
left-out components. Is this also something to be fixed in the cmake script?
Original comment by afterb...@gmail.com
on 8 Sep 2012 at 7:29
Sorry, now I see OgreKitCore depends on BulletCollison, BulletDynamics,
LinearMath, RenderSystem_GLES, and Plugin_ParticleFX. And IPhoneDemo depends on
OgreKitCore. So it should be fine.
But if I change something in RenderSystem_GLES, IPhoneDemo doesn't not
recognize the changes. Maybe it's a Xcode bug, or the GameKit project settings
somehow confused Xcode(?).
Original comment by afterb...@gmail.com
on 9 Sep 2012 at 7:03
Original issue reported on code.google.com by
afterb...@gmail.com
on 25 Jul 2012 at 8:24