Errors building Ogre with Clang (MacOS) and -stdlib=libc++

Problems building or running the engine, queries about how to use features etc.
User avatar
t0tAl_mElTd0wN
Halfling
Posts: 42
Joined: Wed Jan 31, 2007 3:03 pm

Errors building Ogre with Clang (MacOS) and -stdlib=libc++

Post by t0tAl_mElTd0wN »

I have a project that uses features of C++11, and requires the -stdlib=libc++ in Clang.

I'm running XCode 4.5, Apple clang 4.0 (LLVM 3.1), and Ogre 1.8.1. I've verified this error outside of my project. In a nutshell, it looks like Clang doesn't like incomplete types as template parameters in libc++. (Source: http://stackoverflow.com/questions/1006 ... 7#11514677 )

This is the exact error:

Code: Select all

In file included from /Volumes/MacData/Users/edwards/Projects/test/TestProject/TestProject/main.cpp:11:
In file included from /Library/Frameworks/Ogre.framework/Headers/Ogre.h:31:
In file included from /Library/Frameworks/Ogre.framework/Headers/OgrePrerequisites.h:334:
In file included from /Library/Frameworks/Ogre.framework/Headers/OgreStdHeaders.h:122:
In file included from /Library/Frameworks/Ogre.framework/Headers/Threading/OgreThreadHeaders.h:30:
In file included from /Library/Frameworks/Ogre.framework/Headers/Threading/OgreThreadHeadersBoost.h:38:
In file included from /usr/local/include/boost/thread/recursive_mutex.hpp:16:
In file included from /usr/local/include/boost/thread/pthread/recursive_mutex.hpp:12:
In file included from /usr/local/include/boost/thread/locks.hpp:14:
In file included from /usr/local/include/boost/thread/thread_time.hpp:11:
In file included from /usr/local/include/boost/date_time/posix_time/posix_time_types.hpp:16:
/usr/local/include/boost/date_time/posix_time/posix_time_duration.hpp:24:21: warning: implicit conversion loses integer precision: 'long' to 'hour_type' (aka 'int') [-Wshorten-64-to-32]
      time_duration(h,0,0)
      ~~~~~~~~~~~~~ ^
/usr/local/include/boost/date_time/posix_time/posix_time_duration.hpp:35:23: warning: implicit conversion loses integer precision: 'long' to 'min_type' (aka 'int') [-Wshorten-64-to-32]
      time_duration(0,m,0)
      ~~~~~~~~~~~~~   ^
/usr/local/include/boost/date_time/posix_time/posix_time_duration.hpp:46:25: warning: implicit conversion loses integer precision: 'long' to 'sec_type' (aka 'int') [-Wshorten-64-to-32]
      time_duration(0,0,s)
      ~~~~~~~~~~~~~     ^
In file included from /Volumes/MacData/Users/edwards/Projects/test/TestProject/TestProject/main.cpp:11:
In file included from /Library/Frameworks/Ogre.framework/Headers/Ogre.h:31:
In file included from /Library/Frameworks/Ogre.framework/Headers/OgrePrerequisites.h:334:
In file included from /Library/Frameworks/Ogre.framework/Headers/OgreStdHeaders.h:35:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/list:212:9: error: field has incomplete type 'Ogre::Plane'
    _Tp __value_;
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:1889:54: note: in instantiation of template class 'std::__1::__list_node<Ogre::Plane, void *>' requested here
decltype(_VSTD::move(_Tp(_VSTD::declval<_Args>()...)), true_type())
                                                     ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:1890:1: note: while substituting deduced template arguments into function template '__is_constructible_test' [with _Tp = Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>>, _Args = <no value>]
__is_constructible_test(_Tp&&, _Args&& ...);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:1949:14: note: in instantiation of template class 'std::__1::__is_constructible<false, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>>, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>> &>' requested here
    : public __is_constructible<is_scalar<_Tp>::value || is_reference<_Tp>::value,
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:1975:14: note: in instantiation of template class 'std::__1::__is_constructible_void_check<false, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>>, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>> &>' requested here
    : public __is_constructible_void_check<__contains_void<_Tp, _Args...>::value
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2455:34: note: in instantiation of template class 'std::__1::is_constructible<Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>>, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>> &>' requested here
    : __is_nothrow_constructible<is_constructible<_Tp, _Args...>::value, _Tp, _Args...>
                                 ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/type_traits:2583:14: note: (skipping 2 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
    : public is_nothrow_constructible<_Tp, const typename add_lvalue_reference<_Tp>::type>
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2386:15: note: in instantiation of template class 'std::__1::__libcpp_compressed_pair_imp<unsigned long, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>>, 0>' requested here
    : private __libcpp_compressed_pair_imp<_T1, _T2>
              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/list:513:52: note: in instantiation of template class 'std::__1::__compressed_pair<unsigned long, Ogre::STLAllocator<std::__1::__list_node<Ogre::Plane, void *>, Ogre::CategorisedAllocPolicy<0>>>' requested here
    __compressed_pair<size_type, __node_allocator> __size_alloc_;
                                                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/list:770:15: note: in instantiation of template class 'std::__1::__list_imp<Ogre::Plane, Ogre::STLAllocator<Ogre::Plane, Ogre::CategorisedAllocPolicy<0>>>' requested here
    : private __list_imp<_Tp, _Alloc>
              ^
/Library/Frameworks/Ogre.framework/Headers/OgrePrerequisites.h:508:27: note: in instantiation of template class 'std::__1::list<Ogre::Plane, Ogre::STLAllocator<Ogre::Plane, Ogre::CategorisedAllocPolicy<0>>>' requested here
           typedef typename std::list<T, A>::iterator iterator;
                                 ^
/Library/Frameworks/Ogre.framework/Headers/OgreMath.h:627:35: note: in instantiation of template class 'Ogre::list<Ogre::Plane, Ogre::STLAllocator<Ogre::Plane, Ogre::CategorisedAllocPolicy<0>>>' requested here
            const Ray& ray, const list<Plane>::type& planeList, 
                                  ^
/Library/Frameworks/Ogre.framework/Headers/OgrePrerequisites.h:236:11: note: forward declaration of 'Ogre::Plane'
    class Plane;
          ^
Has anyone else seen this before? I've pretty much tracked the issue down to this snippet on the Clang webpage: http://clang.llvm.org/compatibility.htm ... incomplete
The following code is invalid, but compilers are allowed to accept it:

Code: Select all

  class IOOptions;
  template <class T> bool read(T &value) {
    IOOptions opts;
    return read(opts, value);
  }

  class IOOptions { bool ForceReads; };
  bool read(const IOOptions &opts, int &x);
  template bool read<>(int &);
The standard says that types which don't depend on template parameters must be complete when a template is defined if they affect the program's behavior. However, the standard also says that compilers are free to not enforce this rule. Most compilers enforce it to some extent; for example, it would be an error in GCC to write opts.ForceReads in the code above. In Clang, we feel that enforcing the rule consistently lets us provide a better experience, but unfortunately it also means we reject some code that other compilers accept.
This unfortunately seems like Ogre's problem, but is it something that may be fixed in 1.8? Has anyone else encountered this issue? Is there a workaround short of removing our dependency on libc++?

(Most of this code was written for VC++ 2010, where C++11 was supported just fine. It's only now that I'm working on the OSX port that I'm encountering this issue.)
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

I do have code to compile with libc++ but I haven't looked at it in a little while. I'll try to check it out again tomorrow night and see if it's stable enough to push to the 1.8 branch.
User avatar
t0tAl_mElTd0wN
Halfling
Posts: 42
Joined: Wed Jan 31, 2007 3:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by t0tAl_mElTd0wN »

masterfalcon wrote:I do have code to compile with libc++ but I haven't looked at it in a little while. I'll try to check it out again tomorrow night and see if it's stable enough to push to the 1.8 branch.
Oh wow, awesome! Thanks, looking forward to hearing how it turns out.
User avatar
t0tAl_mElTd0wN
Halfling
Posts: 42
Joined: Wed Jan 31, 2007 3:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by t0tAl_mElTd0wN »

Bump. Did you ever get a chance to look at this tonight?
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

No need to bump. I've been very busy this evening. I did find that I could build with libstdc++ and c++11. So maybe that could tide you over for now?
User avatar
t0tAl_mElTd0wN
Halfling
Posts: 42
Joined: Wed Jan 31, 2007 3:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by t0tAl_mElTd0wN »

Oof. That came across pretty rude. Sorry about that, I really appreciate the help.

Unfortunately libstdc++ doesn't include much of the c++11 standard library support, namely <functional> (which large parts of this project rely on).

I'll have a Windows dev environment set up again in a couple days anyway, and there's plenty of work to do there too. The OSX port isn't urgent.

Thanks again.
spectre1989
Gnoblar
Posts: 15
Joined: Mon Oct 01, 2012 10:32 am
x 1

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by spectre1989 »

I'm also working on something that requires some libc++ features. I'm happy to get stuck in with editing the code myself, I just wondered what the best approach to solving this is? Do I need a list of pointers? I tried including OgrePlane.h in OgreMath.h so that Plane wouldn't be incomplete, but then this is a problem as Vector3 also uses OgreMath.h, and Plane contains a Vector3. Should I perhaps move the implementation of Vector3 to a .cpp file, so that OgreMath.h is included in OgreVector3.cpp instead of OgreVector3.h? Am I barking up entirely the wrong tree?

Sorry for word vomit =)
Cheers

J
spectre1989
Gnoblar
Posts: 15
Joined: Mon Oct 01, 2012 10:32 am
x 1

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by spectre1989 »

Quick update on this, I got Ogre to sort of compile with libc++ by doing the following:

In OgrePreRequisites.h, insert after line 33

Code: Select all

// To allow recursive or incomplete types in lists
#include <boost/container/list.hpp>
And replace the list struct contents at line 508 with:

Code: Select all

#if OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR
	   typedef typename boost::container::list<T, A> type;
	   typedef typename boost::container::list<T, A>::iterator iterator;
	   typedef typename boost::container::list<T, A>::const_iterator const_iterator;
#else
		typedef typename boost::container::list<T> type;
		typedef typename boost::container::list<T>::iterator iterator;
		typedef typename boost::container::list<T>::const_iterator const_iterator;
#endif
OgreHardwareVertexBuffer.cpp:503

Code: Select all

mElementList.sort(std::function<bool(const VertexElement&,const VertexElement&)>(VertexDeclaration::vertexElementLess));
I got a bunch of linker errors to resolve which hopefully are just all the dependencies which I haven't compiled yet, it might take me a while to get those sorted.
spectre1989
Gnoblar
Posts: 15
Joined: Mon Oct 01, 2012 10:32 am
x 1

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by spectre1989 »

Another update - I got the linker errors resolved, and got the thing successfully built with the changes I described. I haven't tested it though, as I'm an absolute beginner with Ogre so I don't really know where to start. For now I'm reverting to a pre-built SDK - building Ogre and its dependencies from source got pretty ugly, and it's eaten up way too much time as it is.
User avatar
t0tAl_mElTd0wN
Halfling
Posts: 42
Joined: Wed Jan 31, 2007 3:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by t0tAl_mElTd0wN »

So, an update on this from my end. I made your changes, but then I ran into a few of these:

Code: Select all

In file included from /Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/src/OgreDataStream.cpp:1:
In file included from /Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/include/OgreStableHeaders.h:41:
In file included from /Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/include/OgreArchive.h:31:
In file included from /Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/include/OgrePrerequisites.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:434:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:594:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:1604:18: error: no matching member function for call to 'construct'
            {__a.construct(__p, _VSTD::forward<_Args>(__args)...);}
             ~~~~^~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:1488:14: note: in instantiation of function template specialization 'std::__1::allocator_traits<Ogre::STLAllocator<std::__1::__tree_node<std::__1::pair<std::__1::basic_string<char>, Ogre::ParamCommand *>, void *>, Ogre::CategorisedAllocPolicy<0>> >::__construct<Ogre::ParamCommand *, >' requested here
            {__construct(__has_construct<allocator_type, pointer, _Args...>(),
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/map:1242:20: note: in instantiation of function template specialization 'std::__1::allocator_traits<Ogre::STLAllocator<std::__1::__tree_node<std::__1::pair<std::__1::basic_string<char>, Ogre::ParamCommand *>, void *>, Ogre::CategorisedAllocPolicy<0>> >::construct<Ogre::ParamCommand *, >' requested here
    __node_traits::construct(__na, _VSTD::addressof(__h->__value_.second), _VSTD::forward<_Args>(__args)...);
                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/map:1275:29: note: in instantiation of function template specialization 'std::__1::map<std::__1::basic_string<char>, Ogre::ParamCommand *, std::__1::less<std::__1::basic_string<char>>, Ogre::STLAllocator<std::__1::pair<const std::__1::basic_string<char>, Ogre::ParamCommand *>, Ogre::CategorisedAllocPolicy<0>> >::__construct_node<const std::__1::basic_string<char> &, , void>' requested here
        __node_holder __h = __construct_node(__k);
                            ^
/Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/include/OgreStringInterface.h:136:27: note: in instantiation of member function 'std::__1::map<std::__1::basic_string<char>, Ogre::ParamCommand *, std::__1::less<std::__1::basic_string<char>>, Ogre::STLAllocator<std::__1::pair<const std::__1::basic_string<char>, Ogre::ParamCommand *>, Ogre::CategorisedAllocPolicy<0>> >::operator[]' requested here
            mParamCommands[paramDef.name] = paramCmd;
                          ^
/Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/include/OgreMemorySTLAllocator.h:159:8: note: candidate function not viable: no known conversion from 'Ogre::ParamCommand **' to 'pointer' (aka 'std::__1::__tree_node<std::__1::pair<std::__1::basic_string<char>, Ogre::ParamCommand *>, void *> *') for 1st argument;
                void construct(pointer p)
                     ^
/Volumes/MacData/Users/edwards/Projects/ogre/OgreMain/include/OgreMemorySTLAllocator.h:165:8: note: candidate function not viable: requires 2 arguments, but 1 was provided
                void construct(pointer p, const T& val)
I'm not sure quite what to make of that, but disabling custom allocators for collections seems to work around them at least enough for me to get a functioning application. Looking forward to official libc++ support though. :)

Also: I got those linker errors too. I haven't investigated them entirely yet, but it looks like, at least in my case, boost is expecting a different standard library than Ogre is being compiled with. Boost is looking for functions that exist in libstdc++ and not in libc++. That's my hunch, anyway.
spectre1989
Gnoblar
Posts: 15
Joined: Mon Oct 01, 2012 10:32 am
x 1

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by spectre1989 »

t0tAl_mElTd0wN wrote:So, an update on this from my end. I made your changes, but then I ran into a few of these:
<snip>
I'm not sure quite what to make of that, but disabling custom allocators for collections seems to work around them at least enough for me to get a functioning application. Looking forward to official libc++ support though. :)

Also: I got those linker errors too. I haven't investigated them entirely yet, but it looks like, at least in my case, boost is expecting a different standard library than Ogre is being compiled with. Boost is looking for functions that exist in libstdc++ and not in libc++. That's my hunch, anyway.
Are you using a pre-built version of boost? Also, in my OgreBuildSettings.h I've got #define OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR 0, I haven't tried compiling with it set to 1.
User avatar
t0tAl_mElTd0wN
Halfling
Posts: 42
Joined: Wed Jan 31, 2007 3:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by t0tAl_mElTd0wN »

spectre1989 wrote:
t0tAl_mElTd0wN wrote:So, an update on this from my end. I made your changes, but then I ran into a few of these:
<snip>
I'm not sure quite what to make of that, but disabling custom allocators for collections seems to work around them at least enough for me to get a functioning application. Looking forward to official libc++ support though. :)

Also: I got those linker errors too. I haven't investigated them entirely yet, but it looks like, at least in my case, boost is expecting a different standard library than Ogre is being compiled with. Boost is looking for functions that exist in libstdc++ and not in libc++. That's my hunch, anyway.
Are you using a pre-built version of boost? Also, in my OgreBuildSettings.h I've got #define OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR 0, I haven't tried compiling with it set to 1.
I'm using a version of boost from [Homebrew](http://mxcl.github.com/homebrew/). I'm not sure if there are options in homebrew to compile boost with libc++. I'll look into it this afternoon.
spectre1989
Gnoblar
Posts: 15
Joined: Mon Oct 01, 2012 10:32 am
x 1

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by spectre1989 »

t0tAl_mElTd0wN wrote: I'm using a version of boost from [Homebrew](http://mxcl.github.com/homebrew/). I'm not sure if there are options in homebrew to compile boost with libc++. I'll look into it this afternoon.
Ah ok, it might be worth using the boost headers included in the Ogre source code, and then just download and add any source files you might need (not sure which ones are used by Ogre? Maybe just threading?).
mobileben
Gnoblar
Posts: 13
Joined: Fri Dec 21, 2012 11:34 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by mobileben »

I'm using Xcode 4.5.1, with Apple LLVM compiler 4.1. I too need to use C++11 and hit the snag others hit. It looks like the field has incomplete type 'Ogre::Plane' is caused by by the relationship with OgreMath.h, OgrePlane.h, and OgreVector3.h. There are interdependencies amongst them. (eg. OgreMath depends on Plane, Plane depends on Vector3, Vector3 depends on Math). As an experiment, I got it to compile right by changing removing the dependency of Vector3 on Math. This was done by removing those inlines in Vector3.

At the end of the day, I used the replacement of std::list for boost::container::list which was offered up by spectre1989 since it was a far less invasive change. With the newer compiler, there are more things that need to be fixed. For example, there are a slew of data size narrowing issues.

I also did find that

Code: Select all

#define OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR 0
is needed in OgreBuildSettings.h, or else you get the issue with memory and the "No matching member function for call to 'construct'".

The key at the end of the day for linking was just rebuilding boost with libc++. This is pretty easy to do with the following steps:

-Download the 1.49.0 tar ball
-Update the clang-darwin.jam file. You want to change clang++ to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-Then run the following commands to build.

Code: Select all

$ ./bootstrap.sh --with-libraries=thread,date_time,system,chrono --with-toolset=clang
$ ./b2 --layout=tagged link=static threading=multi toolset=clang cxxflags="-std=gnu++11 -stdlib=libc++ -arch i386 -arch x86_64" linkflags="-stdlib=libc++" target-os=darwin address-model=32_64 install 
This generates a universal binary for both x86_64 and i386.

Just curious, when is there supposed to be proper c+11 support? I read that it was for 2.0?
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

Yeah, definitely not for 1.9. C++11 support is just too big of a change at this point. Would you mind creating a pull request for the changes to get it compiling with libc++? Could you elaborate on the data size narrowing issues? Are there any other issues that you've seen or does it appear to be working properly?
mobileben
Gnoblar
Posts: 13
Joined: Fri Dec 21, 2012 11:34 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by mobileben »

Yeah, I can do that. I still haven't fully tested it yet because I'm dropping it into my own engine framework. Once I validate more of it, I'll create a pull request as well as let you know other issues that pop up.

As far as data narrowing, the problem seems to be with structs. The struct in question is (used in ps_1_4.cpp).

Code: Select all

	struct RegModOffset {
		uint MacroOffset;
		uint RegisterBase;
		uint OpParramsIndex;
	};
the macro R_BASE has the value -35051, which produces this error:

constant expression evaluates to -35051 which cannot be narrowed to type 'uint' (aka 'unsigned int') [-Wc++11-narrowing]

To solve this I made the following change:

Code: Select all

	#define R_BASE  (uint)(sid_R0 - GL_REG_0_ATI)
	#define C_BASE  (uint)(sid_C0 - GL_CON_0_ATI)
	#define T_BASE  (uint)(sid_1T0 - GL_REG_0_ATI)
Note that this is fine:

Code: Select all

uint testVar = R_BASE;
but

Code: Select all

PS_1_4::RegModOffset testVar = { 1, R_BASE, 0 };
will generate the narrowing error. In this case, it seems subject to the narrowing conversion rules, which is an implicit conversion.

Obviously we could turn off the warning, but I generally prefer to have those types of warnings on.

Also, I just upgraded to Xcode 4.6. Things still seem to compile.
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

Ah yes, I recall that warning. I resolved it this way.

Code: Select all

	#define R_BASE  static_cast<unsigned int>((sid_R0 - GL_REG_0_ATI))
	#define C_BASE  static_cast<unsigned int>((sid_C0 - GL_CON_0_ATI))
	#define T_BASE  static_cast<unsigned int>((sid_1T0 - GL_REG_0_ATI))
I have a whole bunch of work toward getting this working as well but I had some sort of runtime issue, can't remember what it was though.
mobileben
Gnoblar
Posts: 13
Joined: Fri Dec 21, 2012 11:34 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by mobileben »

Yeah, static_cast is better. I made the mod on my side I did get up and rendering. Very simple scene using the ogre head and a few of my own models.

RE: the runtime issues you ran into before, do you know if they are related to any particular sample? Since I'm not using my own framework, I can't run the samples, but if there are some better tests, I could rip out parts and try them to see how they fare.

I'll be pushing testing this with iOS soon shortly too, since my framework supports both.

I'm still a bit off from consolidating things, but at least I know I'm doing basic rendering!
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

The latest issue that I ran into was crashing in the ned allocator while loading a config file. So very early on. I just haven't gotten around to looking into why.
sre
Gnoblar
Posts: 10
Joined: Wed Jan 30, 2013 2:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by sre »

I have managed to compile Ogre with -std=c++11 and -stdlib=libc++ with the fixes from above (Deployment target set to 10.8 ).
I didn't test the library with my project yet, but I'm going to do that soon.
I also tried to compile the samples. All sample libs compiled fine but the SampleBrowser did not.
There seems to be an issue with duplicate type names from the Foundation framework:

Code: Select all

In file included from /Users/sre/Documents/Projects/Ogre/Samples/Browser/src/SampleBrowser.cpp:30:
In file included from /Users/sre/Documents/Projects/Ogre/Samples/Browser/include/SampleBrowser.h:71:
/Users/sre/Documents/Projects/Ogre/build/Samples/include/Tesselation.h:59:16: warning: unused variable 'pass' [-Wunused-variable]
        Pass * pass = tMat->getBestTechnique()->getPass(0);
               ^
In file included from /Users/sre/Documents/Projects/Ogre/Samples/Browser/src/SampleBrowser.cpp:37:
In file included from /Users/sre/Documents/Projects/Ogre/Samples/Browser/include/SampleBrowser_OSX.h:42:
In file included from /Users/sre/Documents/Projects/Ogre/RenderSystems/GL/include/OSX/OgreOSXCocoaWindow.h:35:
In file included from /Users/sre/Documents/Projects/Ogre/RenderSystems/GL/include/OSX/OgreOSXCocoaView.h:33:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:76:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:18:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:31:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:244:16: error: reference to 'FileInfo' is ambiguous
typedef struct FileInfo                 FileInfo;
               ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Finder.h:236:8: note: candidate found by name lookup is 'FileInfo'
struct FileInfo {
       ^
/Users/sre/Documents/Projects/Ogre/OgreMain/include/OgreArchive.h:52:12: note: candidate found by name lookup is 'Ogre::FileInfo'
    struct FileInfo {
The same message occurs with Rect.
I didn't try to compile with the default settings because that'll result in link errors with my boost library that links against the libc++.

I really don't understand why clang++ cannot distinguish between Foundation's FileInfo (or Rect) type and Ogre::FileInfo resp. Ogre::Rect.
I also tried to wrap the #inlcude <Cocoa/Cocoa.h> in OgreOSXCocoaView.h in its own namespace but no change.

What helped at a first glance was forward declaring all the cocoa types in the headers that inlcude Cocoa/Cocoa.h and then include Cocoa-h in the implementation .ccp file.
This resolved the error for the files I was able to do the change. However e.g. in OgreOSCocoaWindow.h forward declaring NSWIndow does not help because OgreWindow is derived from NSWindow.

I don't know if this error has something to do with c++11 or with linking against libc++, but maybe is has.
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

As for that error. There's an issue in our cmake files that enables both GL render systems. Just rerun CMake and enable only one of them.
sre
Gnoblar
Posts: 10
Joined: Wed Jan 30, 2013 2:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by sre »

I didn't know there is more than one GL render system.
I run cmake like follows:

Code: Select all

cmake -D OGRE_BUILD_PLUGIN_CG=1 -D OGRE_BUILD_RENDERSYSTEM_GL=1 -D OGRE_CONFIG_CONTAINERS_USE_CUSTOM_ALLOCATOR=0 -D OGRE_STATIC=1  -GXcode ..
How do I disable the other GL render system? Cannot find anything about a second GL render system.
User avatar
masterfalcon
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by masterfalcon »

Use ccmake instead. Make sure that the GL3Plus render system is turned off.
sre
Gnoblar
Posts: 10
Joined: Wed Jan 30, 2013 2:03 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by sre »

Oh, I forgot to mention that I'm on 1.81. I switched to the 1.9 branch, applied the fixes and the error is gone.
Only some linking errors left => OIS but that's another thread.
soulstorm
Gnoblar
Posts: 24
Joined: Sat Jun 08, 2013 7:00 pm

Re: Errors building Ogre with Clang (MacOS) and -stdlib=libc

Post by soulstorm »

So, to clarify, currently Ogre3D needs to be compiled against libstc++ and not libc++, and support for libc++ will possibly come at v 2.0?