[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [42860] trunk/blender/source/blender/ blenkernel/BKE_customdata.h: OSX/gcc-4.6, fix for typedef uin64_t

[Nicholas Bishop]

This recent clang commit might be relevant?
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/unwind.h?view=log&pathrev=146140

That said, I'm getting the same error under Linux with clang.

-Nicholas

On Sat, Dec 24, 2011 at 3:05 PM, Dan Eicher <dan at trollwerks.org> wrote:
> On Sat, Dec 24, 2011 at 1:42 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> I'd rather not have ifdef's like this in every header wherever
>> int64_t/uint64_t is used.
>> perhaps BKE_customdata.h should include BLO_sys_types.h?
>>
>> long term IMHO we should do away with BLO_sys_types.h &
>> MEM_sys_types.h (which are the same file), and have some generic
>> header that can be included anywhere that deals with stdint.h types
>> like intptr_t/ssize_t/int64_t etc.
>>
> Clang building is still broken in trunk because of the redefine of
> u_int64_t thing.
>
> This block is the problem:
>
> /* XXX */
> #ifndef uint64_t
> typedef uint8_t   u_int8_t;
> typedef uint16_t  u_int16_t;
> typedef uint32_t  u_int32_t;
> typedef uint64_t  u_int64_t;
> #endif
>
> I pulled it out of BLO_sys_types.h & MEM_sys_types.h and clang is happy now.
>
> Not sure if this is a proper fix (I don't really understand why it's
> needed in the first place since u_int64_t is gone) but it lets me
> build up to the next error:
>
> In file included from
> /home/dan/blender-svn/blender/extern/libmv/third_party/glog/src/utilities.cc:334:
> /home/dan/blender-svn/blender/extern/libmv/third_party/glog/src/stacktrace_x86_64-inl.h:36:10:
> fatal error:
>      'unwind.h' file not found
> #include <unwind.h> // ABI defined unwinder
>
> which is progress I suppose...
>
> Dan
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers