New XCode Templates for 1.9?

Problems building or running the engine, queries about how to use features etc.
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

New XCode Templates for 1.9?

Post by petrocket »

I tried creating a new iOS project with the 1.8 XCode templates and the project fails to build because:
1. The OgreBites::SDKTrayManager is gone
2. The OgreOverlay headers are in the includes/OGRE/Overlay folder now
3. There are some linking errors with boost

Code: Select all

Undefined symbols for architecture i386:
  "boost::this_thread::get_id()", referenced from:
  Ogre::DefaultWorkQueue::startup(bool) in libOgreMainStatic.a(OgreDefaultWorkQueueStandard.o)
-- EDIT --

I realised that maybe the precompiled iOS dependencies were probably just compiled for armv and not i386 (simulator) so I tried running it on my device instead, but I still get linking errors:

Code: Select all

Undefined symbols for architecture armv7:
  "std::__1::__vector_base_common<true>::__throw_length_error() const", referenced from: void std::__1::vector<std::__1::pair<boost::condition_variable*, boost::mutex*>, 
and some boost ones too

Code: Select all

"boost::this_thread::get_id()", referenced from:
      Ogre::DefaultWorkQueue::startup(bool) in libOgreMainStatic.a(OgreDefaultWorkQueueStandard.o)
I commented out the sdktraymanager stuff and added the include path for the Overlay folder, now I'm trying to fix the boost linking issues. Anyone solved this yet?

Ideally I'd like to make a crossplatform project that I can build on osx, ios and windows, but just trying to get things working on 1.9 first.
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: New XCode Templates for 1.9?

Post by masterfalcon »

I'm guessing that there is a discrepancy with the std c++ library. Unless you chose the option explicitly Ogre will link with stdc++ rather than libc++.

i'll work on the other issues but I just haven't had time to prepare the templates for 1.9 yet.
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

No problemo, I know you're super busy. I'll use 1.8.x till 1.9 is more mature, thanks!
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
jokoon
Goblin
Posts: 203
Joined: Sun Aug 23, 2009 8:30 am
x 3

Re: New XCode Templates for 1.9?

Post by jokoon »

can't wait for 1.9 to ship :)

good luck to maitre faucon :)
futurama1967
Gnoblar
Posts: 1
Joined: Wed Jan 08, 2014 2:38 pm

Re: New XCode Templates for 1.9?

Post by futurama1967 »

hello everone,

i am searching for project templates for xcode 5 and ogre v1-9-0.

any chance?

greetz
futurama
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: New XCode Templates for 1.9?

Post by masterfalcon »

User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

Thought I'd post an update on this for anyone who is interested in using Ogre3d 1.9 RC1 & XCode 5.

From my tests today it appears that using the templates will not give you a buildable application. You have two options:

1. Use libc++
  • - add a user defined build setting called 'OGRE_SDK_ROOT' and point that to your Ogre SDK root (duh)
    - add another search path to Header Search Paths: "$(OGRE_SDK_ROOT)/include/OGRE/Overlay
    - comment out all the OgreBites SDK manager stuff
    - *cry* errors with memory semantic issues
2. Don't use libc++
  • - add a user defined build setting called 'OGRE_SDK_ROOT' and point that to your Ogre SDK root (duh)
    - add another search path to Header Search Paths: "$(OGRE_SDK_ROOT)/include/OGRE/Overlay
    - comment out all the OgreBites SDK manager stuff
    - *cry* errors linking boost libraries (Undefined symbols for architecture i386)
Has anyone got past this on 1.9.x?

*EDIT*
This tutorial doesn't work haha
http://www.ogre3d.org/tikiwiki/tiki-ind ... n+-+iPhone
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

Got it to work. Steps are:
  • - Download 1.9 RC1 SDK: http://sourceforge.net/projects/ogre/fi ... g/download
    - Open .dmg and install
    - Download 1.9 iOS dependancies: http://sourceforge.net/projects/ogre/fi ... g/download
    - Open .dmg and copy iOSDependencies folder to the root of where you installed the SDK
    - Download the templates and install: http://sourceforge.net/projects/ogre/fi ... p/download
    - Open XCode -> File -> New Project
    - Create the project (DON'T select the libc++ option)
    - Go to the project build settings and then Editor->Add Build Setting->Add User Defined Setting. The Setting should be OGRE_SDK_ROOT and the value should be the path to the SDK root.
    - Still in build settings modify the Header Search Paths to add "$(OGRE_SDK_ROOT)/include/OGRE/Overlay"
    - Make sure c++ Language Dialect is GNU++11 and C++ Standard Library is libstdc++ in Build Settings
    - Make sure the Library Search Paths are "$(OGRE_SDK_ROOT)/lib/Release" "$(OGRE_SDK_ROOT)/lib" "$(OGRE_SDK_ROOT)/iOSDependencies/lib/Release" ORDER IS IMPORTANT
    - Open OgreDemoApp.cpp and comment out line 100 (destroy shader generator line)
    - Open OgreFramework.cpp and OgreFramework.h and comment out or remove ALL m_pTrayMgr lines.
    - Run it.
    - Cry tears of joy. :cry:
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
jefalcon
Gnoblar
Posts: 8
Joined: Mon Oct 15, 2012 12:12 pm

Re: New XCode Templates for 1.9?

Post by jefalcon »

petrocket, I,ve follow your brief tutorial but don´t work

Code: Select all

Ld Build/Products/Debug-iphonesimulator/pruebaogreSDK.app/pruebaogreSDK normal i386
    cd /Users/javi/3d/proyectos/ogresdk/pruebaogreSDK
    setenv IPHONEOS_DEPLOYMENT_TARGET 7.0
    setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -L/Users/javi/3d/proyectos/ogresdk/pruebaogreSDK/Build/Products/Debug-iphonesimulator -L/Users/javi/3d/OgreSDK/lib/Release -L/Users/javi/3d/OgreSDK/lib -L/Users/javi/3d/OgreSDK/iOSDependencies/lib/Release -F/Users/javi/3d/proyectos/ogresdk/pruebaogreSDK/Build/Products/Debug-iphonesimulator -filelist /Users/javi/3d/proyectos/ogresdk/pruebaogreSDK/Build/Intermediates/pruebaogreSDK.build/Debug-iphonesimulator/pruebaogreSDK.build/Objects-normal/i386/pruebaogreSDK.LinkFileList -Xlinker -objc_abi_version -Xlinker 2 -lOIS -lOgreMainStatic -lRenderSystem_GLES2Static -lOgreRTShaderSystemStatic -lglsl_optimizer -lboost_system -lboost_chrono -lboost_date_time -lboost_thread -lFreeType -lFreeImage -lzzip -lz -stdlib=libstdc++ -Xlinker -no_implicit_dylibs -fobjc-link-runtime -mios-simulator-version-min=7.0 -framework QuartzCore -framework CoreGraphics -framework Foundation -framework OpenGLES -framework UIKit -Xlinker -dependency_info -Xlinker /Users/javi/3d/proyectos/ogresdk/pruebaogreSDK/Build/Intermediates/pruebaogreSDK.build/Debug-iphonesimulator/pruebaogreSDK.build/Objects-normal/i386/pruebaogreSDK_dependency_info.dat -o /Users/javi/3d/proyectos/ogresdk/pruebaogreSDK/Build/Products/Debug-iphonesimulator/pruebaogreSDK.app/pruebaogreSDK

Undefined symbols for architecture i386:
  "Ogre::OverlayElement::isVisible() const", referenced from:
      OgreBites::SdkTrayManager::frameRenderingQueued(Ogre::FrameEvent const&) in OgreFramework.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
any idea to solve it?
Thanks in advance
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: New XCode Templates for 1.9?

Post by masterfalcon »

The OS X and iOS 1.9 SDKs and Xcode templates have been updated. Please download them to see if they help with the issue.
jefalcon
Gnoblar
Posts: 8
Joined: Mon Oct 15, 2012 12:12 pm

Re: New XCode Templates for 1.9?

Post by jefalcon »

It works :) but I get a lot of warnings

Code: Select all

ld: warning: direct access in boost::thread::start_thread() to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::start_thread() to global weak symbol vtable for boost::thread_resource_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::start_thread(boost::thread_attributes const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::start_thread(boost::thread_attributes const&) to global weak symbol vtable for boost::thread_resource_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::start_thread(boost::thread_attributes const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::start_thread(boost::thread_attributes const&) to global weak symbol vtable for boost::thread_resource_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::join() to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::join() to global weak symbol vtable for boost::thread_resource_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::do_try_join_until(timespec const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::thread::do_try_join_until(timespec const&) to global weak symbol vtable for boost::thread_resource_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::this_thread::interruption_point() to global weak symbol typeinfo for boost::thread_interrupted means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::condition_variable::do_timed_wait(boost::unique_lock<boost::mutex>&, timespec const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::condition_variable::do_timed_wait(boost::unique_lock<boost::mutex>&, timespec const&) to global weak symbol vtable for boost::condition_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::condition_variable::do_timed_wait(boost::unique_lock<boost::mutex>&, timespec const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::condition_variable::do_timed_wait(boost::unique_lock<boost::mutex>&, timespec const&) to global weak symbol vtable for boost::condition_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::mutex::lock() to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::mutex::lock() to global weak symbol vtable for boost::lock_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_tag) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_tag) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_tag) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_tag) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::thread_resource_error> const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::thread_resource_error> const&) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::thread_resource_error> const&) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::thread_resource_error> const&) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::mutex::mutex() to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::mutex::mutex() to global weak symbol vtable for boost::thread_resource_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_tag) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_tag) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_tag) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > const&, boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_tag) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::condition_error> const&) to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::condition_error> const&) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::condition_error> const&) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> >::clone_impl(boost::exception_detail::error_info_injector<boost::condition_error> const&) to global weak symbol vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::condition_error> > means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

It hasn't to comment the m_pTrayMgr lines... With the new template all works
Thanks to all
krisztiantobias
Gnoblar
Posts: 19
Joined: Mon Feb 11, 2013 7:23 pm

Re: New XCode Templates for 1.9?

Post by krisztiantobias »

jefalcon wrote:It works :) but I get a lot of warnings
Do not disturb You, I have more than 600 just in Ogre Base.

OFF:

I see here is a lot of men with knowledgeable. It's off topic, but I'm doing my thesis and in NxOgre forum has nothing and the mod didn't enabled yet my write.
I'm really sorry my trespass, bur I have Only 25 days left so please help :roll:

I use the newest Nxogre, but it's not works perfectly. The convex cylinder passes the ball sphere and I really don't know why.
If I'm using with more less power or I hit on side the ball is good, but it's not enough for me of course.

Here is a gif of the problem:
Image
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

masterfalcon wrote:The OS X and iOS 1.9 SDKs and Xcode templates have been updated. Please download them to see if they help with the issue.
Closer!
I downloaded the 1.9.0 iOS SDK, the iOSDependencies and the latest templates and installed them. I then created a new iOS project and added the OGRE_SDK_ROOT build setting and hit run! Unfortunately, for me the build failed to link saying symbols not found for architecture i386 (OIS, OgreMainStatic, boost etc.) . The weird thing is I checked those libraries with lipo - info and they DO have i386 libs in them, so could it be something wrong with other build settings?

Then I switched the C++ Standard Library Build Setting to libc++ and the build linked successfully for i386 (simulator) but failed to link for iOS device (boost armv7s missing symbols even though lipo says they're in there).

Also, the same project does build and link fine if I switch $(OGRE_SDK_ROOT) to the 1.9.0 RC1 SDK, comment out the shadergenerator::destroy line and add in the path to $(OGRE_SDK_ROOT)/lib after the $(OGRE_SDK_ROOT)/lib/Release Library Search Path entry.

Also, the 1.9.0 SDK has a "boost" folder in the root that maybe shouldn't be there? It seems to have the same contents as the "include/boost" folder.

*EDIT*
I also don't understand why there are multiple libboost libraries - one set in OGRE_SDK_ROOT/lib and one in OGRE_SDK_ROOT/iOSDependencies/lib
There's also libOIS, libFreeImage in OGRE_SDK_ROOT/lib/Release and in OGRE_SDK_ROOT/iOSDependencies/lib/Release
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
sauron
Gnoblar
Posts: 1
Joined: Fri Apr 18, 2014 7:06 pm

Re: New XCode Templates for 1.9?

Post by sauron »

Hi all,
i'm trying to use the OSX template for Ogre 1.9. I've never programmed Ogre for OSX(or anything for OSX for that matter) so it took some time i got the empty Ogre project from the OSX Template to build.
The problem is when i Run the program after a successful build it crashes with the following error:

Code: Select all

dyld: Library not loaded: @executable_path/../Frameworks/OgreOverlay.framework/Versions/1.9.0/OgreOverlay
  Referenced from: /Users/xx/Library/Developer/Xcode/DerivedData/OgreTest2-ahbgkdyfbngiitbifflguudgvugq/Build/Products/Debug/OgreTest2.app/Contents/MacOS/OgreTest2
  Reason: image not found
(lldb) 
Looking at the error i would say it can't find OgreOverlay, but it should be there...
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

Has anyone got this Ogre 1.9 SDK to work on an iOS device yet?

I tried fiddling with this again and only managed to get the simulator version to compile with these steps:
1. Create new Ogre project
2. Add $(OGRE_SDK_ROOT) user build setting with path to 1.9 SDK
3. Change C++ Standard Library to libc++
4. Build for simulator

If I switch to build for device I get:
Undefined symbols for architecture armv7s:
"boost::atomics::detail::lockpool::get_lock_for(void const volatile*)", referenced from:
boost::thread_detail::enter_once_region(boost::once_flag&) in libboost_thread.a(once.o)
boost::thread_detail::commit_once_region(boost::once_flag&) in libboost_thread.a(once.o)
boost::thread_detail::rollback_once_region(boost::once_flag&) in libboost_thread.a(once.o)
ld: symbol(s) not found for architecture armv7s
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

To answer my own question:
To build for device simply remove armv7s from the valid architectures in the build settings and they you can build.
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
Anidrium
Gnoblar
Posts: 3
Joined: Sat May 31, 2014 1:28 am

Re: New XCode Templates for 1.9?

Post by Anidrium »

At Other Linker Flags, add -lboost_atomic after -lboost_thread.
This solved the issue for me.
Anidrium
Gnoblar
Posts: 3
Joined: Sat May 31, 2014 1:28 am

Re: New XCode Templates for 1.9?

Post by Anidrium »

sauron wrote:Hi all,
i'm trying to use the OSX template for Ogre 1.9. I've never programmed Ogre for OSX(or anything for OSX for that matter) so it took some time i got the empty Ogre project from the OSX Template to build.
The problem is when i Run the program after a successful build it crashes with the following error:

Code: Select all

dyld: Library not loaded: @executable_path/../Frameworks/OgreOverlay.framework/Versions/1.9.0/OgreOverlay
  Referenced from: /Users/xx/Library/Developer/Xcode/DerivedData/OgreTest2-ahbgkdyfbngiitbifflguudgvugq/Build/Products/Debug/OgreTest2.app/Contents/MacOS/OgreTest2
  Reason: image not found
(lldb) 
Looking at the error i would say it can't find OgreOverlay, but it should be there...
Hi there.
To fix this, At Project Settings, Build Phases / Run Script, change the line
ditto “$OGRE_SDK_ROOT/lib/macosx/Release/OgreOverlay.framework” “$BUILT_PRODUCTS_DIR/Test.app/Contents/Frameworks/OgreOverlay.framework”
to
ditto “$OGRE_SDK_ROOT/lib/macosx/Release/OgreOverlay.framework” “$BUILT_PRODUCTS_DIR//Contents/Frameworks/OgreOverlay.framework”

This happens because the template referentes "Test.app" instead your own application.

To fix the template, edit /Users/<Your User>/Library/Developer/Xcode/Templates/Ogre/Mac OS X Application.xctemplate/TemplateInfo.plist
and change the line
ditto "$OGRE_SDK_ROOT/lib/macosx/Release/OgreOverlay.framework" "$BUILT_PRODUCTS_DIR/Test.app/Contents/Frameworks/OgreOverlay.framework"

To

ditto "$OGRE_SDK_ROOT/lib/macosx/Release/OgreOverlay.framework" "$BUILT_PRODUCTS_DIR/___PACKAGENAME___.app/Contents/Frameworks/OgreOverlay.framework"

This way, whenever you create a new project from the template, it will be already fixed.

Regards,
HerkO
Gnoblar
Posts: 6
Joined: Sun Jan 18, 2015 4:08 am

New XCode Templates for 1.9

Post by HerkO »

Using the new (April 2014) Xcode Template for Ogre-1.9 and the OgreSDK_v1-9-0.dmg binary install of Ogre on OS X Mavericks 10.9.5, I get the following error with the Template DemoApplication and with Basic Tutorial1:

dyld`dyld_fatal_error:
0x7fff5fc0109c: int3
0x7fff5fc0109d: nop

With the following message displayed in the console.

With the Xcode Template Demo:
---------------------------------------
dyld: Library not loaded: @executable_path/../Frameworks/OgreOverlay.framework/Versions/1.9.0/OgreOverlay
Referenced from: /Users/Herk/Library/Developer/Xcode/DerivedData/Build/Products/Debug/OgreDmgInstall.app/Contents/MacOS/OgreDmgInstall
Reason: image not found
(lldb)

With Basic Tutorial1:
-------------------------
dyld: Library not loaded: @executable_path/../Frameworks/OgreOverlay.framework/Versions/1.9.0/OgreOverlay
Referenced from: /Users/Herk/Library/Developer/Xcode/DerivedData/Build/Products/Debug/BasicTutorial1.app/Contents/MacOS/BasicTutorial1
Reason: image not found
(lldb)

The fix described above by Anidrium didn't correct the problem. Any suggestion would be appreciated.

Thanks.

HerkO.
HerkO
Gnoblar
Posts: 6
Joined: Sun Jan 18, 2015 4:08 am

Re: Previous post & New XCode Templates for 1.9?

Post by HerkO »

Re my previous post (just above):
I believe the problem may be due to the Xcode Template for Ogre-1.9 not copying the "OgreOverlay.framework" into the executable's Framework directory (/Users/xxx/Library/Developer/Xcode/DerivedData/Build/Products/Debug/BasicTutorial1.app/Contents/Frameworks), where it's currently being looked for by the application and where the template does copy "Ogre.framework" & "RenderSystem_GL.framework".

Not sure where the solution lies.
jokoon
Goblin
Posts: 203
Joined: Sun Aug 23, 2009 8:30 am
x 3

Re: New XCode Templates for 1.9?

Post by jokoon »

Did anyone manage to make ogre3d+ois work fine on xcode ? I abandoned on xcode 5, should I try some more on xcode 6 ? Should I roll up my own simple 3D engine instead, or just give up mac os x ? Anyone who managed to use a solid makefile to make a project ? Are the template really advised to run ogre on mac, can't I use ogre3d without those templates ?

I'm still willing to use Ogre for my pet project, I'd love to see it work on my mac, but I have not had the courage to fix the gimmicks I often encounter on it, shame on me :(
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

Do you mean Ogre3D+iOS ? I did get an OSX and iOS build running, though I'm not certain how up to date this repo is. Try comparing the build settings on my OSX and iOS projects to yours and it might help you build with the SDK.

https://github.com/petrocket/OgreGameKit

However, be aware that I have been facing a lot of crashing related to the RTShader system, which might mean that I have to roll my own shaders for everything. Just FYI.
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
jokooon
Gnoblar
Posts: 3
Joined: Sat Jan 31, 2015 8:56 pm

Re: New XCode Templates for 1.9?

Post by jokooon »

petrocket wrote:Do you mean Ogre3D+iOS ?
Not iOS, but OIS, the input system.
jokooon
Gnoblar
Posts: 3
Joined: Sat Jan 31, 2015 8:56 pm

Re: New XCode Templates for 1.9?

Post by jokooon »

Seems the CMake scripts are pretty broken.

I quickly tried to regenerate the CMake scripts of the OgreSDK (I don't know if I'm even supposed to do it at all, all I know is that when I run the sample in the XCode project, it fails because there's no make rule or something).

http://imgur.com/xCUGxR9

So I re ran CMake on that SDK, run XCode, and there are missing folders in the includes.

Whatever, I don't particularly care about the samples. What I wish was, somebody who could help craft a decent xcodeproj file that can run Ogre and the OIS input system. I don't necessarily want a xcode template, just a xcodeproj file, or a tutorial to make one.

http://www.bizicbojan.com/post/2014/05/ ... e-511.aspx

This tutorial is telling me to disable C++11 (!). It also requires MacOSX10.5.sdk , which if I heard right, was having problems with making OIS work.
User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
x 10
Contact:

Re: New XCode Templates for 1.9?

Post by petrocket »

I use OIS for input in that repository on OSX and iOS I believe.
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket
Post Reply