Python Forum
Is there a problem with LONG_BIT in pyconfig.h ?
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is there a problem with LONG_BIT in pyconfig.h ?

I am trying to make some code that I wrote in C++ available to me in Python. To do this, I am trying out pybind11. But I am running into a compile error. I know there are other ways, but this seemed an elegant solution that I'm not quite ready to give up on.

The way this works is, in my C++ code, I need to include headers from pybind11, and Python.h from my python installation. I'm using 64-bit compilation of C++ (cygwin64), and I have downloaded a recent 64-bit version of python to my machine ( It's a self-install.

The problem I'm running into is that when I compile my C++ code with "#include <Python.h>" I get the following error from pyport.h.

error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).

I can see that LONG_BIT is defined in pyconfig.h: "#define LONG_BIT 32"

But is that correct? I'm not familiar with the code, but my intuition would be that for a 64-bit version of python, LONG_BIT should be 64. Just for kicks, I tried to make this simple change to 64, but this led to more compile errors.

Is anyone familiar with this? Can anyone give me some guidance? Much appreciated.

I'm not familiar with pybind11 but I have written some C extensions for Windows.

The standard ABI for Windows defines a C long as 32 bits on both 32-bit and 64-bit versions of Windows. The "long long" type is defined as 64 bits. This standard is followed by the Microsoft Visual Studio compilers which are used to compile the binaries that are downloaded from

IIRC, the cygwin64 compiler defines a C long at 64 bits. That compiler should work with there own version of Python but won't work with a standard 64-bit Windows binary. That is probably the source of the problem.

I generally use either the free (to download) Microsoft compilers or MSYS2 and the mingw64 compiler.


Thank you for the feedback. I think you are right, that I'm supposed to be using the cygwin64 include files while in the C++ development environment, and not the python include files. Once I do this, I get a different bunch of errors. So progress.

Anyway, I'm going to try cython for making my C++ code available in Python. I'm not sure pybind11 is supported in CLion.

Thanks for the help. Much appreciated.

The issue isn't just using the cygwin64 include files, it is also using the cygwin64 Python interpreter. If your original C++ library was compiled under cygwin64, then it thinks a C long has 64 bits. I think the cygwin64 compiled Python (and the related include files) also think a C long has 64 bits. So those should all work together.

But the standard Python for Windows thinks a C long has 32 bits and a C long long has 64 bits.

I use "long long" when I need to map a 64-bit integer Python on Windows. This is supported by Visual Studio and mingw64.

I don't know if Cython can resolve the issues of incompatible C compilers.

My recommendation would be to use VS or MSYS2/mingw64 and define your own types so you can use long on Linux and long long on Windows. That should work with either pybind11 or Cython.


Thanks again for your help! I greatly appreciate it. Though I've been programming a while, I find these sorts of build issues very tricky.

I probably didn't understand every word of what you said, but I got the idea that Python for Windows and cygwin64 have incompatible definitions of C long which can be problematic when trying to make C++ and Python work together.

As a result, and also because when I started to work with Cython I had to download the Microsoft SDK C/C++ compiler to compile the Cython extensions, I tried using Microsoft Visual Studio C++ Community Edition to build my test code. I saw the Community Editions of Visual Studio C++ and Python are available for free. Now using the MS VS x86 (32-bit) compiler, and the Python 36-32 distribution I managed to get my pybind11 test case to compile. In addition, I can also build a sample Cython module. Next thing you know I'll manage to get Python ctypes LoadLibrary to load a dll. :)

Thanks again for the help. I think I'm up and running. My take away from this is that when using new tools, it's probably best and easiest to use the well-worn paths.


Forum Jump:

User Panel Messages

Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020