Failed to compile with Python 3.6.0 on 32-bit Linux

Issue #389 resolved
Felix Yan
created an issue

I am getting the following error when trying to compile rpy2 2.8.5 with Python 3.6.0 on i686:

In file included from ./rpy/rinterface/_rinterface.c:64:0:
/usr/include/R/Rinterface.h:106:24: error: conflicting types for 'uintptr_t'
  typedef unsigned long uintptr_t;
In file included from /usr/lib/gcc/i686-pc-linux-gnu/6.2.1/include/stdint.h:9:0,
                 from /usr/include/inttypes.h:27,
                 from /usr/include/python3.6m/pyport.h:6,
                 from /usr/include/python3.6m/Python.h:50,
                 from ./rpy/rinterface/_rinterface.c:49:
/usr/include/stdint.h:128:23: note: previous declaration of 'uintptr_t' was here
 typedef unsigned int  uintptr_t;

Comments (8)

  1. Laurent Gautier

    It seems like a definition in Rinterface.h is conflicting with a definition in the system's stdint.h. The R definition is calling it uintptr_t while it an unsigned long. I don't know how I can avoid that from rpy2. At first sight, reporting to upstream (R and/or Python) might be the best. What is the version of R you are trying this with ?

  2. Laurent Gautier

    I had a quick look at this and the definition in Rinterface.h is a conditional one:

    #if !defined(HAVE_UINTPTR_T) && !defined(uintptr_t)
     typedef unsigned long uintptr_t;

    There should be a way to fix this in rpy2 without asking upstream.

  3. Laurent Gautier

    R-core has identified this as a potential issue and there is a proposed fixed upstream (in R-devel - not yet sure about which R version will first include the fix). Thanks for the report (turns out that it is helping make R better).

    Update: other voice in R core saying it is a feature, not a bug and checking the presence of uintptr_t the responsibility of code embedding R. <sigh>

  4. Laurent Gautier

    The changelog for R-3.4.0 has: """ HAVE_UINTPTR_T is now defined where appropriate by Rconfig.h so that it can be included before Rinterface.h when CSTACK_DEFNS is defined and a C compiler (not C++) is in use. Rinterface.h now includes C header ‘stdint.h’ or C++11 header ‘cstdint’ where needed. """

    Can someone check whether this was finally solved upstream (or not) ? Thanks.

  5. Log in to comment