[Numpy-discussion] numpy int64_t incompatibility on OSX

[Adam Klein]

I am cross-posting this question; I think this question is more
numpy-related than cython-related.  Original question is at bottom.

In OSX 10.6, C system headers such as /usr/include/i386/types.h (as well
as other standard headers like C99 stdint.h) define int64_t as

  typedef *long long* int64_t;

Whereas npy_common.h defines the following incompatible type when included
(I traced it to line 258 via the gcc -E switch):

  typedef *long* npy_int64

As a result, I get conflicts when mixing standard library and numpy int64_t
variables (during normal Cythoning on OSX).

A quick hackaround, I can alter the npy_common.h file to look like this:

#ifdef OSX_INT64_LONG_LONG
        typedef long long npy_int64;
        typedef unsigned long long npy_uint64;
#else
        typedef long npy_int64;
        typedef unsigned long npy_uint64;
#endif

And define the OSX_INT64_LONG_LONG macro in my build, in setup.py.

Has anyone had this sort of incompatibility on OSX? Suggestions as to
correct way to deal with it?

Thanks,
  Adam


On Mon, Dec 19, 2011 at 1:37 PM, mark florisson
<markflorisson88 at gmail.com>wrote:
>
>> On 19 December 2011 00:04, Adam Klein <adam at lambdafoundry.com> wrote:
>> > Hi all,
>> >
>> > I'm getting the following error:
>> >
>> > source.cpp:1969: error: invalid conversion from
>> ‘__pyx_t_5numpy_int64_t*’ to
>> > ‘int64_t*’
>> >
>> > I am on OSX (10.6).  Same make compiles fine on Linux.
>> >
>> > The problematic compiler command:
>> >
>> > /usr/bin/llvm-gcc -fno-strict-aliasing -fno-common -dynamic -arch i386
>> -arch
>> > x86_64 -O3 -march=core2 -w -pipe -DNDEBUG -g -fwrapv -O3 -Wall
>> > -Wstrict-prototypes
>> >
>> -I/Volumes/HD2/adam/.virtualenvs/py27/lib/python2.7/site-packages/numpy/core/include
>> >
>> -I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/include/python2.7
>> > -c source.cpp -o build/temp.macosx-10.5-intel-2.7/source.o
>> >
>> > I figured out that if I take out the flag "-arch x86_64", it builds.
>> >
>> > I don't have any ARCHFLAGS or CFLAGS defined otherwise in my
>> environments.
>> >
>> > Any ideas?
>> >
>> > Thanks!
>> >
>> > --Adam
>>
>> Hm, could you paste the full compiler output and possibly the source code?
>>
>
> I figured out, using the -E switch of gcc, that /usr/include/i386/types.h
> is being included, which defines int64_t as
>
> #ifndef _INT64_T
>
> #define _INT64_T
> typedef long long int64_t;
> #endif
>
> It seems to be chosen from /usr/include/machine,
>
> #elif defined (__i386__) || defined(__x86_64__)
> #include "i386/types.h"
>
> This matches the stdint.h definition in /usr/include/stdint.h.
>
> This all conflicts with the npy_common.h definition,
>
> #elif NPY_BITSOF_LONG == 64
> #define NPY_INT64 NPY_LONG
> #define NPY_UINT64 NPY_ULONG
>         typedef long npy_int64;
>
> I'm still trying to find an OSX header int64_t definition that isn't
> defined as "long long"...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111223/b62dc616/attachment.html>