Compile python extensions error

Error — Compile Cython extensions #11

I have followed the instruction to install everything expect the MPI.

I go the «Comple Cython Extensions» Stage by running the : python3 setup.py build_ext —inplace
The error happen :
Traceback (most recent call last):
File «setup.py», line 43, in
os.environ[‘CC’] = glob.glob(‘/usr/local/bin/gcc-[4-5]*’)[0].split(os.sep)[-1]
IndexError: list index out of range

Could you let me how to fix this error,please?

The text was updated successfully, but these errors were encountered:

Can you tell me a bit more about what machine and OS you are using? From the error you are getting I’m guessing it is Mac OS X. On Mac OS X you need to have gcc installed which is easiest done via Homebrew (http://brew.sh). The error you are getting suggests Python can’t find gcc which is used to compile the Cython extensions.

I am using the lastest Macbook Pro and Mac Mini as well with lastest apple
OS version: OS X El Capitan.

I did follow the instruction which guide me to Homebrew (http://brew.sh)
and by simply copy and paste the commend:
ruby -e «$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/mas
And it successful installed.

Is there way to check whether I have installed it in the properly way or
not.

Meanwhile, I did install Xcode in my Mac Mini but not in my Macbook Pro.
And it give me the same error.

Looking forward your reply.

On Mon, Nov 23, 2015 at 10:34 AM, Craig Warren notifications@github.com
wrote:

Can you tell me a bit more about what machine and OS you are using? From
the error you are getting I’m guessing it is Mac OS X. On Mac OS X you need
to have gcc installed which is easiest done via Homebrew (http://brew.sh).
The error you are getting suggests Python can’t find gcc which is used to
compile the Cython extensions.

—
Reply to this email directly or view it on GitHub
#11 (comment).

Homebrew is just a package manager, you must use it to install gcc, e.g. brew install gcc

I have run brew install gcc and then run «python3 setup.py build_ext
—inplace»

But a serious error happen and I copy the last two line :

_/var/folders/_j/9q99q_6x7v765l86cy_v8y040000gp/T//ccZ4acjb.s:74636:13:
*_error:
*register %rip is only available in 64-bit mode

error: command ‘gcc-5’ failed with exit status 1

Is there any hit to fix this prolem?

On Mon, Nov 23, 2015 at 11:20 AM, Craig Warren notifications@github.com
wrote:

Homebrew is just a package manager, you must use it to install gcc, e.g.
brew install gcc

—
Reply to this email directly or view it on GitHub
#11 (comment).

I can’t tell what has gone wrong from those lines. Please attach or copy/paste more of the error messages from gcc.

I was try to copy the error but it seems so long and I cannot attached the
.txt file.
So I share a google fold shared link and please check with that.​
GPRmax Installation
https://docs.google.com/folderview?id=0B48AviLQL3OTYllhS1VnaTNkQnM&usp=drive_web
​
Many thanks

On Wed, Nov 25, 2015 at 9:47 AM, Craig Warren notifications@github.com
wrote:

I can’t tell what has gone wrong from those lines. Please attach or
copy/paste more of the error messages from gcc.

—
Reply to this email directly or view it on GitHub
#11 (comment).

Can you check you are using Python 3. python usually points to Python 2.7 python3 usually points to Python 3.

I am show the path and also the pip list.
I run the python for version 2.7 and python3 for version 3 as well.
It is given me the same error.

On Wed, Nov 25, 2015 at 1:00 PM, Craig Warren notifications@github.com
wrote:

Can you check you are using Python 3. python usually points to Python 2.7
python3 usually points to Python 3.

—
Reply to this email directly or view it on GitHub
#11 (comment).

gprMax is only compatible with Python 3.x. The error you are seeing is happening at the point that gcc is being used to compile the C files that have been generated by Cython. Can you run gcc-5 -v and paste the output here please.

After running the commend «gcc-5 -v «, the result is shown as:

fengzhouwang1$ gcc-5 -v

Using built-in specs.

Configured with: ../configure —build=x86_64-apple-darwin15.0.0
—prefix=/usr/local/Cellar/gcc/5.2.0
—libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
—enable-languages=c,c++,objc,obj-c++,fortran —program-suffix=-5
—with-gmp=/usr/local/opt/gmp —with-mpfr=/usr/local/opt/mpfr
—with-mpc=/usr/local/opt/libmpc —with-isl=/usr/local/opt/isl
—with-system-zlib —enable-libstdcxx-time=yes —enable-stage1-checking
—enable-checking=release —enable-lto —with-build-config=bootstrap-debug
—disable-werror —with-pkgversion=’Homebrew gcc 5.2.0′ —with-bugurl=
https://github.com/Homebrew/homebrew/issues —enable-plugin —disable-nls
—enable-multilib

Thread model: posix

gcc version 5.2.0 (Homebrew gcc 5.2.0)

On Wed, Nov 25, 2015 at 1:43 PM, Craig Warren notifications@github.com
wrote:

gprMax is only compatible with Python 3.x. The error you are seeing is
happening at the point that gcc is being used to compile the C files that
have been generated by Cython. Can you run gcc-5 -v and paste the output
here please.

—
Reply to this email directly or view it on GitHub
#11 (comment).

Источник

Compiling Python extensions on Windows

21 December 2014 (updated 28 March 2017)

Extensions usually need to be built with the same compiler version as the interpreter. This is because each compiler version uses a different and incompatible CRT, until VS 2015 that is. You can read more about that here.

If you’re missing the required compiler you usually get a vague error: Unable to find vcvarsall.bat.

For Python 2.7 *

For Python 2.7 you need to get Microsoft Visual C++ Compiler for Python 2.7. It’s a special package made by Microsoft that has all the stuff. It is supported since setuptools 6.0 [1].

Unfortunately the latest virtualenv, 1.11.6 as of now, still bundles setuptools 3.6 . This means that if you try to run python setup.py build_ext in an virtualenv it will fail, because setuptools can’t detect the compiler. The solution is to force upgrade setuptools, example: pip install «setuptools>=6.0» .

If you’re using tox then just add it to your deps. Example:

This seems to work fine for 64bit extensions.

Probably works for Python 3.3 too.

For Python 3.4 *

This one gave me a headache. I’ve tried to follow this guide but had some problems with getting 64bit extensions to compile. In order to get it to work you need to jump through these hoops:

Before installing the Windows SDK v7.1 (these gave me a bad time):

• Do not install Microsoft Visual Studio 2010 Service Pack 1 yet. If you did then you have to reinstall everything. Uninstalling the Service Pack removes components so you have to reinstall Visual C++ 2010 Express again.
• Remove all the Microsoft Visual C++ 2010 Redistributable packages from Control PanelPrograms and Features .

If you don’t do those then the install is going to fail with an obscure » Fatal error during installation » error.

Install Windows SDK for Visual Studio 2010 (v7.1) (download). This is required for 64bit extensions.

⚠ On Windows 10 the web installer gets confused:

Some Windows SDK components require the RTM .NET Framework 4. Setup detected a pre-release version of the .NET Framework 4.

You certainly don’t need any of the .NET stuff so you can work around by getting the offline version of the SDK (ISO) (download).

• Make sure you download GRMSDKX_EN_DVD.iso ( X means 64bit).
• Windows has builtin mounting for ISOs. Just mount the ISO and run SetupSDKSetup.exe instead of setup.exe.

Create a vcvars64.bat file in C:Program Files (x86)Microsoft Visual Studio 10.0VCbinamd64 that contains [2]:

If you don’t do this you’re going to get a mind-boggling error like this:

msvc9_support.py will run vcvarsall.bat amd64:

Basically that is caused by vcvarsall.bat not being able to run vcvar64.bat because, surprise, the Windows SDK is missing that file.

Now everything should work, go and try py -3 setup.py clean —all build_ext —force .

Install Microsoft Visual Studio 2010 Service Pack 1 (download). This is optional, however, if you do this you also have to do the following too [3]:

Remove all those SQL Server packages that you don’t need from Control PanelPrograms and Features .

Alternative: Victor Stinner argues that just installing the Windows SDKs ( v7.0 for Python 2.7, v7.1 for Python 3.3 and 3.4) is enough if you prepare the environment (inconvenient in my opinion):

See his notes or the Python wiki. You still need to install those fiddly SDKs 🙂

For Python 3.5 *

It seems Visual Studio 2015 Community Edition just works without any fuss. Get it here. It’s quite big and doesn’t let you skip the irrelevant SQL Server and .NET tools so I had to manually remove them from Control PanelPrograms and Features .

Alternative: Get the Visual C++ 2015 Build Tools instead. It doesn’t come with Visual Studio and all the useless cruft but make sure you select the Windows 8.1 SDK during the install.

This entry was tagged as pip python windows

© Copyright by Ionel Cristian Mărieș. Powered by Pelican. Theme based on flasky.

Источник

Compiling C extension modules on Windows (Cython)

This page describes how to compile a Cython extension (works for CPython extensions also) for Windows.

If you encounter one of the following errors:

Then you are at the right place! These errors simply mean that you lack a C compiler to compile the .c files generated by Cython from your .pyx files. On Linux, the solution is easy, and most users do not even have to install anything special because the “platform compiler”, gcc, is already installed. On Windows, it is a little bit more complicated, since the platform compiler is not installed by default, so you have to do it by yourself.

Below we describe the two currently available ways to install the platform compiler on Windows and set it up so that you can compile the C extension for Python on Windows.

Using Microsoft Visual C++ Compiler for Python (only for Python 2.7.x)

NOTE: the following works only for Python 2.7 and 3.2, for Python 3.3 and 3.4 you should try the older method with the SDK.

The easiest way to compile correctly working C and Cython extensions for Python on Windows is to use Visual Studio SDK, because incompatibilities may arise when using other compilers. However, the process (outlined below) can be quite daunting and will consume several GB of installation, only to get a working compiler.

Microsoft fairly recently released a freely distributed version of their compiler specifically for building Python extensions for the python.org 2.7 series, called Microsoft Visual C++ Compiler for Python, which is only

85MB and should work for most Python compiling purposes.

This version does not have a couple of bugs that made it hard to get set up properly for 64-bit extensions. Before proceeding to the instructions below, you should update setuptools to at least 6.0.

Here is how to compile C extensions using Microsoft Visual C++ Compiler for Python:

1. Install Microsoft Visual C++ Compiler for Python from http://www.microsoft.com/en-us/download/details.aspx?id=44266
2. Create a setup.py loading setuptools instead of distutils. Setuptools will monkey-patch distutils and find vcvarsall.bat. For example, this won’t work:

But the following will:

For the rest of setup.py, read the tutorial at .

When using an IPython Notebook, you can apply the same trick:

Now, you should be able to compile your C extensions, and even Cython extensions if you have Cython installed. If you still get an error about not finding vcvarsall.bat, you may try the following workarounds:

1. Install Microsoft Visual C++ Compiler for Python (as described above).
2. Launch MSVC for Python command prompt
   (go to start menu > Microsoft Visual C++ Compiler Package for Python 2.7 > Visual C++ 2008 32-bit Command Prompt)
3. Enter the following commands:
   SET DISTUTILS_USE_SDK=1SET MSSdk=1
4. You can then “cd X:yourpath” to navigate to your Python app and then build your C extensions by entering:
   python.exe setup.py build_ext –inplace –compiler=msvc

Steps 2 and 3 must be reproduced every time before building your C extensions. This is because of an issue with the VCForPython27.msi which installs the header files and vcvarsall.bat in folders with a different path layout than the VS2008 SDK and thus confuses the compiler detection of distutils. This will maybe get fixed in distutils for Python 2.7.11.

However, if you want to use IPython/Jupyter and the %%cython magic, you cannot specify the —compiler nor enter the required variables to workaround the detection issue (thus %%cython will always try to compile using mingw).

Another way to work around this issue, without needing to set variables every time, is to patch the file C:yourpythoninstallLibdistutilsmsvc9compiler.py by adding the following code at the top of the find_vcvarsall() function:

Then, create a file distutils.cfg in the same folder, and put this inside:

Now you can compile C extensions without any prior manipulations. Thus you can now call the %%cython magic inside IPython/Jupyter, by placing this inside a cell:

For more information about this detection issue, see the bug report and workaround by Gregory Szorc: http://bugs.python.org/issue23246

And for a discussion about providing more info on compiler detection errors: https://github.com/pypa/pip/issues/942 http://bugs.python.org/issue2943

Note: Enthought Canopy users, see here

Note2: don’t try the GccWithBinaries project, even though it will install with a 32-bit Python (whatever the bits of the installed Windows), The Cython extension won’t compile. Same with standard MinGW, and same with GCC. https://github.com/develersrl/gccwinbinaries

Note3: to compile your Cython scripts, you need to either use pyximport or make a setup.py as described at http://docs.cython.org/src/tutorial/cython_tutorial.html> and which seems to generate setup.py compatible with Cython.

Using Windows SDK C/C++ compiler (works for all Python versions)

The standard way to compile C extensions for CPython (including Cython extensions) is to install the compiler that was used to compile the CPython interpreter. CPython is always compiled using Visual Studio.

In order to do this, you either need the Visual Studio that compiled CPython or a Windows SDK C/C++ compiler. Now the problem is that depending on which Python version you want to compile your extension for, you need a different version of the SDK because they are not cross-compatible.

Luckily, people have compiled the list of CPython versions with their corresponding SDK, and in fact, you can use the free Visual Studio Express v9.0 package to compile Python between versions 2.6.9 – 3.3.4, VSE v10.0 (2010) to compile Python 3.3.5 – 3.4.x, and Visual Studio 2015 Community Edition for Python 3.5. Make sure that you check the “Common tools for Visual C++” option during the Visual Studio install (in order to avoid the dreaded vcvarsall.bat error ). Note that this only works for compiling 32-bits extensions, for 64-bits extensions you will need to install in addition the corresponding Windows SDK below.

Here are two good listings where you will find all the necessary info to install the correct Visual Studio for your Python:

If you don’t want to install Visual Studio, you can choose to install the Windows SDK C/C++ compiler, as indicated in the table below:

At this point, it does not matter if you want to compile for 64 or 32 bit. The version you downloaded can do both.

Before you run something along the lines of

to install or build a package, you do have to start an SDK Command Prompt or CMD Shell and set some environment variables.

By default, the shell starts at the installation path of the Windows SDK (C:Program FilesMicrosoft SDKsWindowsv7.0. There, we have to do two things:

1. Tell distutils / setuptools to use the Microsoft SDK compiler
2. Tell the compiler to compile a 32 or 64-bit release and whether it should be a debug or a release build

Thus, we have to enter two commands

Assuming you haven’t changed the Windows SDK installation path, this looks something like this

As you might have guessed, you can swap out x64 for x86 or /release for /debug and vice versa.

Then, switch to your project directory and try to python setup.py command_name or pip install package_name . This should work now.

Additional information

The C/C++ compiler and linker that comes with the Windows SDK should be used because Python itself is compiled with it. That way your extensions will always be binary compatible with Python and other installed system components and libraries.

You should find the SDK Command Prompt or the CMD Shell in the start menu. In case you don’t find it, check your Windows SDK installation path (default: C:Program FilesMicrosoft SDKsWindowsv7.0 )

Less useful information

** Do not use MinGW-w64. As you will notice, the MinGW import library for Python (e.g. libpython27.a) is omitted from the AMD64 version of Python. This is deliberate. Do not try to make one using dlltool. There is no official MinGW-w64 release yet, it is still in “beta” and considered unstable, although you can get a 64-bit build from e.g. TDM-GCC. There have also been issues with the mingw runtime conflicting with the MSVC runtime; this can happen from places you don’t expect, such as inside runtime libraries for g++ or gfortran. To stay on the safe side, avoid MinGW-w64 for now.

** Those with experience in Linux or Apple MacOSX might pick GCC (MinGW) as their C/C++ compiler of choice on Windows. Note that GCC is not the platform C compiler on Windows. To be binary compatible with most libraries and applications on Windows, use Microsoft’s compiler. This is no different from selecting GCC as the compiler of choice on Linux. Microsoft’s platform C/C++ compiler for Windows is free of charge.

** For C++, observe that GCC (Mingw) and MSVC use different C++ runtimes. If you use C++ in your extension, the C++ runtime must also be compatible with Python’s C runtime. For this reason, always use Microsoft’s compiler for C++, even on 32-bit x86. This is very important on a platform like Windows where C++ is pervasive (cf. COM and ActiveX). If you use GCC as a C++ compiler your extension will not be binary compatible with other C++ libraries or COM, not be compatible with Python’s C runtime, and differences in exception handling between GCC and MSVC can crash your application.

** If you need Fortran (e.g. for f2py or fwrap), Intel, Absoft and Portland have compilers compatible with Microsoft’s C compiler and linker. Be very careful if you use an unofficial MinGW-w64 build of gfortran, as libgfortran is linked against an incompatible C runtime. Unlike C and C++, there is no freely available Fortran compiler except MinGW-w64 gfortran on Windows 64.

** If you prefer to use Microsoft Visual C++ for editing and debugging, the SDK can be registered with the commercial version of Microsoft Visual Studio. For Python 2.6, 2.7, and 2.8, you will need Visual Studio 2008.

Источник

Hello ,

After running the commend «gcc-5 -v «, the result is shown as:

Fengzhous-MacBook-Pro:~ fengzhouwang1$ gcc-5 -v

Using built-in specs.

COLLECT_GCC=gcc-5

COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin15.0.0/5.2.0/lto-wrapper

Target: x86_64-apple-darwin15.0.0

Configured with: ../configure —build=x86_64-apple-darwin15.0.0
—prefix=/usr/local/Cellar/gcc/5.2.0
—libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
—enable-languages=c,c++,objc,obj-c++,fortran —program-suffix=-5
—with-gmp=/usr/local/opt/gmp —with-mpfr=/usr/local/opt/mpfr
—with-mpc=/usr/local/opt/libmpc —with-isl=/usr/local/opt/isl
—with-system-zlib —enable-libstdcxx-time=yes —enable-stage1-checking
—enable-checking=release —enable-lto —with-build-config=bootstrap-debug
—disable-werror —with-pkgversion=’Homebrew gcc 5.2.0′ —with-bugurl=
https://github.com/Homebrew/homebrew/issues —enable-plugin —disable-nls
—enable-multilib

Thread model: posix

gcc version 5.2.0 (Homebrew gcc 5.2.0)

Kind regards.

Fengzhou

On Wed, Nov 25, 2015 at 1:43 PM, Craig Warren notifications@github.com
wrote:

gprMax is only compatible with Python 3.x. The error you are seeing is
happening at the point that gcc is being used to compile the C files that
have been generated by Cython. Can you run gcc-5 -v and paste the output
here please.

—
Reply to this email directly or view it on GitHub
#11 (comment).

user@user-computer:~$ gcc
The program 'gcc' is currently not installed. You can install it by typing:
sudo apt-get install gcc
user@user-computer:~$ sudo apt-get install gcc
[sudo] password for user: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
gcc is already the newest version.
The following packages were automatically installed and are no longer required:
  libseccomp2 libwireshark5 libwiretap4 libwsutil4
  linux-image-3.13.0-160-generic linux-image-extra-3.13.0-160-generic
  linux-lts-xenial-tools-4.4.0-137 linux-signed-image-4.4.0-137-generic
  linux-tools-4.4.0-137-generic squashfs-tools
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
user@user-computer:~$ gcc
The program 'gcc' is currently not installed. You can install it by typing:
sudo apt-get install gcc

Ответы
2

sudo apt install --reinstall gcc

$ sudo apt-get install python-dev

$ sudo apt-get install python3-dev

$ sudo apt-get install python3.8-dev

Другие вопросы по теме

user@user-computer:~$ gcc
The program 'gcc' is currently not installed. You can install it by typing:
sudo apt-get install gcc
user@user-computer:~$ sudo apt-get install gcc
[sudo] password for user: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
gcc is already the newest version.
The following packages were automatically installed and are no longer required:
  libseccomp2 libwireshark5 libwiretap4 libwsutil4
  linux-image-3.13.0-160-generic linux-image-extra-3.13.0-160-generic
  linux-lts-xenial-tools-4.4.0-137 linux-signed-image-4.4.0-137-generic
  linux-tools-4.4.0-137-generic squashfs-tools
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
user@user-computer:~$ gcc
The program 'gcc' is currently not installed. You can install it by typing:
sudo apt-get install gcc

2 ответа

Лучший ответ

sudo apt install --reinstall gcc

$ sudo apt-get install python-dev

$ sudo apt-get install python3-dev

$ sudo apt-get install python3.8-dev

10 mins read

This page describes how to compile a Cython extension (works for CPython extensions also) for Windows.

If you encounter one of the following errors:

C:yourprojectpath python setup.py build_ext --inplace --compiler=msvc
running build_ext
building 'helloworld' extension
error: Unable to find vcvarsall.bat

Then you are at the right place! These errors simply mean that you lack a C compiler to compile the .c files generated by Cython from your .pyx files. On Linux, the solution is easy, and most users do not even have to install anything special because the “platform compiler”, gcc, is already installed. On Windows, it is a little bit more complicated, since the platform compiler is not installed by default, so you have to do it by yourself.

Below we describe the two currently available ways to install the platform compiler on Windows and set it up so that you can compile the C extension for Python on Windows.

Using Microsoft Visual C++ Compiler for Python (only for Python 2.7.x)

NOTE: the following works only for Python 2.7 and 3.2, for Python 3.3 and 3.4 you should try the older method with the SDK.

The easiest way to compile correctly working C and Cython extensions for Python on Windows is to use Visual Studio SDK, because incompatibilities may arise when using other compilers. However, the process (outlined below) can be quite daunting and will consume several GB of installation, only to get a working compiler.

Microsoft fairly recently released a freely distributed version of their compiler specifically for building Python extensions for the python.org 2.7 series, called Microsoft Visual C++ Compiler for Python, which is only ~85MB and should work for most Python compiling purposes.

This version does not have a couple of bugs that made it hard to get set up properly for 64-bit extensions. Before proceeding to the instructions below, you should update setuptools to at least 6.0.

Here is how to compile C extensions using Microsoft Visual C++ Compiler for Python:

1. Install Microsoft Visual C++ Compiler for Python from http://www.microsoft.com/en-us/download/details.aspx?id=44266
2. Create a setup.py loading setuptools instead of distutils. Setuptools will monkey-patch distutils and find vcvarsall.bat. For example, this won’t work:

from distutils.core import setup
from distutils.extension import Extension

But the following will:

try:
    from setuptools import setup
    from setuptools import Extension
except ImportError:
    from distutils.core import setup
    from distutils.extension import Extension

For the rest of setup.py, read the tutorial at <http://www.sefidian.com/2017/06/17/basic-tutorial-of-cython/>.

When using an IPython Notebook, you can apply the same trick:

#First cell:
import setuptools
%load_ext Cython

#Second cell:
%%cython -a
import cython
cimport cython

cdef int alpha = 255
print alpha

Now, you should be able to compile your C extensions, and even Cython extensions if you have Cython installed. If you still get an error about not finding vcvarsall.bat, you may try the following workarounds:

1. Install Microsoft Visual C++ Compiler for Python (as described above).
2. Launch MSVC for Python command prompt
   (go to start menu > Microsoft Visual C++ Compiler Package for Python 2.7 > Visual C++ 2008 32-bit Command Prompt)
3. Enter the following commands:
   SET DISTUTILS_USE_SDK=1SET MSSdk=1
4. You can then “cd X:yourpath” to navigate to your Python app and then build your C extensions by entering:
   python.exe setup.py build_ext –inplace –compiler=msvc

Steps 2 and 3 must be reproduced every time before building your C extensions. This is because of an issue with the VCForPython27.msi which installs the header files and vcvarsall.bat in folders with a different path layout than the VS2008 SDK and thus confuses the compiler detection of distutils. This will maybe get fixed in distutils for Python 2.7.11.

However, if you want to use IPython/Jupyter and the %%cython magic, you cannot specify the --compiler nor enter the required variables to workaround the detection issue (thus %%cython will always try to compile using mingw).

Another way to work around this issue, without needing to set variables every time, is to patch the file C:yourpythoninstallLibdistutilsmsvc9compiler.py by adding the following code at the top of the find_vcvarsall() function:

def find_vcvarsall(version):
"""Find the vcvarsall.bat file

At first it tries to find the productdir of VS 2008 in the registry. If
that fails it falls back to the VS90COMNTOOLS env var.
"""
vsbase = VS_BASE % version
vcpath = os.environ['ProgramFiles']
vcpath = os.path.join(vcpath, 'Common Files', 'Microsoft',
'Visual C++ for Python', '9.0', 'vcvarsall.bat')
if os.path.isfile(vcpath): return vcpath
vcpath = os.path.join(os.environ['LOCALAPPDATA'], 'Programs', 'Common', 'Microsoft', 'Visual C++ for Python', '9.0', 'vcvarsall.bat')
if os.path.isfile(vcpath): return vcpath
...

Then, create a file distutils.cfg in the same folder, and put this inside:

Now you can compile C extensions without any prior manipulations. Thus you can now call the %%cython magic inside IPython/Jupyter, by placing this inside a cell:

%load_ext Cython
%%cython

For more information about this detection issue, see the bug report and workaround by Gregory Szorc: http://bugs.python.org/issue23246

And for a discussion about providing more info on compiler detection errors: https://github.com/pypa/pip/issues/942 http://bugs.python.org/issue2943

Note: Enthought Canopy users, see here

Note2: don’t try the GccWithBinaries project, even though it will install with a 32-bit Python (whatever the bits of the installed Windows), The Cython extension won’t compile. Same with standard MinGW, and same with GCC. https://github.com/develersrl/gccwinbinaries

Note3: to compile your Cython scripts, you need to either use pyximport or make a setup.py as described at http://docs.cython.org/src/tutorial/cython_tutorial.html> and <http://docs.cython.org/src/reference/compilation.html.

You can also try distcontrib <http://distcontrib.readthedocs.org/en/latest/> which seems to generate setup.py compatible with Cython.

Using Windows SDK C/C++ compiler (works for all Python versions)

The standard way to compile C extensions for CPython (including Cython extensions) is to install the compiler that was used to compile the CPython interpreter. CPython is always compiled using Visual Studio.

In order to do this, you either need the Visual Studio that compiled CPython or a Windows SDK C/C++ compiler. Now the problem is that depending on which Python version you want to compile your extension for, you need a different version of the SDK because they are not cross-compatible.

Luckily, people have compiled the list of CPython versions with their corresponding SDK, and in fact, you can use the free Visual Studio Express v9.0 package to compile Python between versions 2.6.9 – 3.3.4, VSE v10.0 (2010) to compile Python 3.3.5 – 3.4.x, and Visual Studio 2015 Community Edition for Python 3.5. Make sure that you check the “Common tools for Visual C++” option during the Visual Studio install (in order to avoid the dreaded vcvarsall.bat error). Note that this only works for compiling 32-bits extensions, for 64-bits extensions you will need to install in addition the corresponding Windows SDK below.

Here are two good listings where you will find all the necessary info to install the correct Visual Studio for your Python:

https://matthew-brett.github.io/pydagogue/python_msvc.html

http://blog.ionelmc.ro/2014/12/21/compiling-python-extensions-on-windows/

If you don’t want to install Visual Studio, you can choose to install the Windows SDK C/C++ compiler, as indicated in the table below:

At this point, it does not matter if you want to compile for 64 or 32 bit. The version you downloaded can do both.

Before you run something along the lines of

or

python setup.py command_name

to install or build a package, you do have to start an SDK Command Prompt or CMD Shell and set some environment variables.

By default, the shell starts at the installation path of the Windows SDK (C:Program FilesMicrosoft SDKsWindowsv7.0. There, we have to do two things:

1. Tell distutils / setuptools to use the Microsoft SDK compiler
2. Tell the compiler to compile a 32 or 64-bit release and whether it should be a debug or a release build

Thus, we have to enter two commands

set DISTUTILS_USE_SDK=1
setenv /x64 /release

Assuming you haven’t changed the Windows SDK installation path, this looks something like this

C:Program FilesMicrosoft SDKsWindowsv7.0>set DISTUTILS_USE_SDK=1
C:Program FilesMicrosoft SDKsWindowsv7.0>setenv /x64 /release

As you might have guessed, you can swap out x64 for x86 or /release for /debug and vice versa.

Then, switch to your project directory and try to python setup.py command_name or pip install package_name. This should work now.

Finally, you should distribute your binary package as a .whl file to PyPi.

Additional information

The C/C++ compiler and linker that comes with the Windows SDK should be used because Python itself is compiled with it. That way your extensions will always be binary compatible with Python and other installed system components and libraries.

You should find the SDK Command Prompt or the CMD Shell in the start menu. In case you don’t find it, check your Windows SDK installation path (default: C:Program FilesMicrosoft SDKsWindowsv7.0)

Less useful information

** Do not use MinGW-w64. As you will notice, the MinGW import library for Python (e.g. libpython27.a) is omitted from the AMD64 version of Python. This is deliberate. Do not try to make one using dlltool. There is no official MinGW-w64 release yet, it is still in “beta” and considered unstable, although you can get a 64-bit build from e.g. TDM-GCC. There have also been issues with the mingw runtime conflicting with the MSVC runtime; this can happen from places you don’t expect, such as inside runtime libraries for g++ or gfortran. To stay on the safe side, avoid MinGW-w64 for now.

** Those with experience in Linux or Apple MacOSX might pick GCC (MinGW) as their C/C++ compiler of choice on Windows. Note that GCC is not the platform C compiler on Windows. To be binary compatible with most libraries and applications on Windows, use Microsoft’s compiler. This is no different from selecting GCC as the compiler of choice on Linux. Microsoft’s platform C/C++ compiler for Windows is free of charge.

** For C++, observe that GCC (Mingw) and MSVC use different C++ runtimes. If you use C++ in your extension, the C++ runtime must also be compatible with Python’s C runtime. For this reason, always use Microsoft’s compiler for C++, even on 32-bit x86. This is very important on a platform like Windows where C++ is pervasive (cf. COM and ActiveX). If you use GCC as a C++ compiler your extension will not be binary compatible with other C++ libraries or COM, not be compatible with Python’s C runtime, and differences in exception handling between GCC and MSVC can crash your application.

** If you need Fortran (e.g. for f2py or fwrap), Intel, Absoft and Portland have compilers compatible with Microsoft’s C compiler and linker. Be very careful if you use an unofficial MinGW-w64 build of gfortran, as libgfortran is linked against an incompatible C runtime. Unlike C and C++, there is no freely available Fortran compiler except MinGW-w64 gfortran on Windows 64.

** If you prefer to use Microsoft Visual C++ for editing and debugging, the SDK can be registered with the commercial version of Microsoft Visual Studio. For Python 2.6, 2.7, and 2.8, you will need Visual Studio 2008.

process

Created on 2014-02-25 13:33 by Antoine.Brodin.FreeBSD, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (33)
msg212176 — (view)	Author: Antoine Brodin.FreeBSD (Antoine.Brodin.FreeBSD)	Date: 2014-02-25 13:33
Hi, On FreeBSD -current, clang 3.4 is now the default compiler. Clang 3.4 rejects "-R/path/to/lib" flag (previously in version 3.3 it just ignored it). This leads to some errors with some python extensions: cc -shared -O2 -pipe -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cache.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/connection.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cursor.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/microprotocols.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/module.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/prepare_protocol.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/row.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/statement.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/util.o -L/usr/local/lib -R/usr/local/lib -lsqlite3 -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_sqlite3.so cc: error: unknown argument: '-R/usr/local/lib' error: command 'cc' failed with exit status 1 cc -shared -O2 -pipe -DLDAP_DEPRECATED -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/LDAPObject.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/ldapcontrol.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/common.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/constants.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/errors.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/functions.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/schema.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/ldapmodule.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/message.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/version.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/options.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/berval.o -L/usr/local/lib -L/usr/lib -R/usr/local/lib -R/usr/lib -lldap_r -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_ldap.so cc: error: unknown argument: '-R/usr/local/lib' cc: error: unknown argument: '-R/usr/lib' error: command 'cc' failed with exit status 1 cc -shared -O2 -pipe -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/Modules/_bsddb.o -L/usr/local/lib -R/usr/local/lib -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/bsddb3/_pybsddb.so -ldb-4.3 cc: error: unknown argument: '-R/usr/local/lib' error: command 'cc' failed with exit status 1 I found the patch below to help, it is for function runtime_library_dir_option in Lib/distutils/unixccompiler.py -Wl,-rpath works for both gcc and clang on freebsd --- ./Lib/distutils/unixccompiler.py.orig +++ ./Lib/distutils/unixccompiler.py @@ -228,6 +228,8 @@ if sys.platform[:6] == "darwin": # MacOSX's linker doesn't understand the -R flag at all return "-L" + dir + elif sys.platform[:7] == "freebsd": + return "-Wl,-rpath=" + dir elif sys.platform[:5] == "hp-ux": if self._is_gcc(compiler): return ["-Wl,+s", "-L" + dir]
msg212177 — (view)	Author: Kubilay Kocak (koobs)	Date: 2014-02-25 13:40
Details on how clang 3.4 changes behaviour for compiler flags: http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html#new-compiler-flags
msg212185 — (view)	Author: Matthias Klose (doko) *	Date: 2014-02-25 15:48
this looks safe from my point of view. However the real problem is that you unconditionally add a runtime path for a standard system path. I think the better way to fix this is not to pass the -L and -R arguments at all if the library is found in a system path.
msg212188 — (view)	Author: Antoine Brodin.FreeBSD (Antoine.Brodin.FreeBSD)	Date: 2014-02-25 16:45
For the python-ldap extension, this seems to be a buglet in its setup.cfg, it lists /usr/lib in library_dirs and /usr/include in library_dirs For the others, /usr/local/lib is not in the default library search path (only /lib and /usr/lib) so at least -L has to be specified.
msg212193 — (view)	Author: Martin v. Löwis (loewis) *	Date: 2014-02-25 18:26
doko: how do you know the addition of the -R option is unconditional? and whom do you refer to by "you" who is adding the option? In any case, the patch is independent of whether the option is added unconditionally, and I agree that the patch looks safe. The question is whether it should be extended to the other *BSDs as well.
msg212415 — (view)	Author: Kubilay Kocak (koobs)	Date: 2014-02-28 09:04
Attaching patch against default
msg212419 — (view)	Author: STINNER Victor (vstinner) *	Date: 2014-02-28 10:32
> The question is whether it should be extended to the other *BSDs as well. The change is not needed on Linux (if Clang 3.4 is used to compile extensions too)?
msg212718 — (view)	Author: Kubilay Kocak (koobs)	Date: 2014-03-04 13:23
It would be great if this could make it into 3.4, extended to include other OS's if necessary at a later date.
msg212719 — (view)	Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *	Date: 2014-03-04 13:38
https://bugs.gentoo.org/show_bug.cgi?id=503352 suggests that this problem occurs also on Linux when using Clang.
msg215310 — (view)	Author: Dirkjan Ochtman (djc) *	Date: 2014-04-01 13:12
Can we have some more feedback on this?
msg215312 — (view)	Author: STINNER Victor (vstinner) *	Date: 2014-04-01 13:16
See also issue #21122.
msg215315 — (view)	Author: Dirkjan Ochtman (djc) *	Date: 2014-04-01 13:29
That does look to be a different issue, though.
msg257021 — (view)	Author: Stefan Krah (skrah) *	Date: 2015-12-26 10:27
Over at the llvm bug tracker this is marked as a release blocker: https://llvm.org/bugs/show_bug.cgi?id=18164
msg270077 — (view)	Author: Stefan Krah (skrah) *	Date: 2016-07-10 08:50
Strange, why can anyone edit the classification? It happens a lot lately.
msg270767 — (view)	Author: Stéphane Wirtel (matrixise) *	Date: 2016-07-18 15:58
I have checked the status of the FreeBSD issue, and it's "New". What do you think for the fix ?
msg271845 — (view)	Author: Evelyn Mitchell (Evelyn Mitchell) *	Date: 2016-08-02 19:39
The patch looks reasonable, but needs to be tested on FreeBSD.
msg271850 — (view)	Author: Kubilay Kocak (koobs)	Date: 2016-08-02 20:56
Nothing is required (as far as I'm aware) other than commit/merge on a two line change scoped only to FreeBSD. The issue was reported for and on FreeBSD and the patch has been carried locally in all FreeBSD Python ports/packages (2.7, 3.3, 3.4, 3.5) for over two years: https://svnweb.freebsd.org/ports?view=revision&revision=346428 https://svnweb.freebsd.org/ports?view=revision&revision=351610
msg271851 — (view)	Author: Evelyn Mitchell (Evelyn Mitchell) *	Date: 2016-08-02 21:00
I think this patch should pass to the next stage. Thank you, koobs.
msg271852 — (view)	Author: Stefan Krah (skrah) *	Date: 2016-08-02 21:08
We can of course commit this, but could you also lobby here? https://llvm.org/bugs/show_bug.cgi?id=18164 I'm seeing this quite often that we fix something here and no one insists on the upstream bug trackers.
msg271856 — (view)	Author: Evelyn Mitchell (Evelyn Mitchell) *	Date: 2016-08-02 21:35
Stefan, I've commented on the llvm bugzilla. Thanks for suggesting that.
msg271857 — (view)	Author: Kubilay Kocak (koobs)	Date: 2016-08-02 21:35
@Stefan I've notified our FreeBSD Clang/LLVM people of the upstream bug status, though there are indications that the "-Wl,-rpath" method is considered the recommended/canonical/future way to do things properly.
msg271883 — (view)	Author: Roundup Robot (python-dev)	Date: 2016-08-03 09:19
New changeset 441bbf4cc914 by Stefan Krah in branch '3.5': Issue #20767: Fix -R option for FreeBSD/clang. https://hg.python.org/cpython/rev/441bbf4cc914
msg271884 — (view)	Author: Roundup Robot (python-dev)	Date: 2016-08-03 09:23
New changeset 65eb8d0ede75 by Stefan Krah in branch '2.7': Issue #20767: Fix -R option for FreeBSD/clang. https://hg.python.org/cpython/rev/65eb8d0ede75
msg271885 — (view)	Author: Stefan Krah (skrah) *	Date: 2016-08-03 09:26
@Evelyn @koobs Thanks for communicating with the other projects that are involved in this issue! Could you double-check that especially the 2.7 patch does exactly what you want? For 2.7 it's practically a one time chance.
msg271889 — (view)	Author: Kubilay Kocak (koobs)	Date: 2016-08-03 10:19
@Stefan I'll touch base with Antoine (OP) and confirm that this is a root-cause, permanent solution
msg271890 — (view)	Author: Kubilay Kocak (koobs)	Date: 2016-08-03 10:26
Not sure why the stage field changed on last submission. Restore accordingly to previous state
msg281845 — (view)	Author: Stefan Krah (skrah) *	Date: 2016-11-28 08:07
I guess the FreeBSD people are happy with the solution.
msg310437 — (view)	Author: STINNER Victor (vstinner) *	Date: 2018-01-22 17:35
> I guess the FreeBSD people are happy with the solution. According to the discussion on https://github.com/python/cpython/pull/5233 : some FreeBSD people are unhappy :-)
msg310446 — (view)	Author: Stefan Krah (skrah) *	Date: 2018-01-22 18:27
Well, they had ample time to articulate themselves. :)
msg311315 — (view)	Author: Kubilay Kocak (koobs)	Date: 2018-01-31 07:48
The changeset(s) applied in this issue were/are fine (thus no response on the issue) It is the *removal* of the changesets included in this issue (as proposed in https://github.com/python/cpython/pull/5233) that would re-break compilation of extensions with clang (requiring re-opening this issue) The root cause of the current confusion is the special case added here was conditional on the OS ('freebsd'), whereas it should (arguably) have been for a specific compiler (clang). In order to do this, this leads to the compiler detection code requiring improvement, see: https://github.com/python/cpython/pull/5233#issuecomment-358906977 as it currently does not detect clang as the default compiler (cc), see: https://github.com/python/cpython/pull/5233#issuecomment-358948425
msg311316 — (view)	Author: Kubilay Kocak (koobs)	Date: 2018-01-31 07:51
If the intent is to use this issue to track the resolution of the original issue (clang compilation broken) and cover the new PR (which just moves the code from os detection to compiler detection), then it can remain open. Otherwise it can be closed, as the original issue 'has' been fixed.
msg334606 — (view)	Author: Larry Hastings (larry) *	Date: 2019-01-31 06:00
It's too late to fix this for Python 3.4 and 3.5, as those are now in security-fixes-only mode. Also, please don't select every possible component that could be remotely connected.
msg334620 — (view)	Author: STINNER Victor (vstinner) *	Date: 2019-01-31 10:26
> If the intent is to use this issue to track the resolution of the original issue (clang compilation broken) and cover the new PR (which just moves the code from os detection to compiler detection), then it can remain open. Otherwise it can be closed, as the original issue 'has' been fixed. Ok, I close the issue. On https://github.com/python/cpython/pull/5233 bapt asked "code changes", but I don't understand what exactly and I'm not interested to continue to work on these changes. If someone is interested, please open a new issue (pointing to this one).

For Python 2.7 *

For Python 2.7 you need to get Microsoft Visual C++ Compiler for Python 2.7. It’s a special package made by Microsoft that has all the stuff. It is supported since setuptools 6.0 [1].

Unfortunately the latest virtualenv, 1.11.6 as of now, still bundles setuptools 3.6. This means that if you try to run python setup.py build_ext in an virtualenv it will fail, because setuptools can’t detect the compiler. The solution is to force upgrade setuptools, example: pip install «setuptools>=6.0».

If you’re using tox then just add it to your deps. Example:

[testenv]
deps =
    setuptools>=6.0

This seems to work fine for 64bit extensions.

For Python 3.4 *

This one gave me a headache. I’ve tried to follow this guide but had some problems with getting 64bit extensions to compile. In order to get it to work you need to jump through these hoops:

1. Install Visual C++ 2010 Express (download).

2. Before installing the Windows SDK v7.1 (these gave me a bad time):

   • Do not install Microsoft Visual Studio 2010 Service Pack 1 yet. If you did then you have to reinstall everything. Uninstalling the Service Pack removes components so you have to reinstall Visual C++ 2010 Express again.
   • Remove all the Microsoft Visual C++ 2010 Redistributable packages from Control PanelPrograms and Features.

   If you don’t do those then the install is going to fail with an obscure «Fatal error during installation» error.

3. Install Windows SDK for Visual Studio 2010 (v7.1) (download). This is required for 64bit extensions.

   ⚠ On Windows 10 the web installer gets confused:

   Some Windows SDK components require the RTM .NET Framework 4. Setup detected a pre-release version of the .NET Framework 4.

   You certainly don’t need any of the .NET stuff so you can work around by getting the offline version of the SDK (ISO) (download).

   • Make sure you download GRMSDKX_EN_DVD.iso (X means 64bit).
   • Windows has builtin mounting for ISOs. Just mount the ISO and run SetupSDKSetup.exe instead of setup.exe.

4. Create a vcvars64.bat file in C:Program Files (x86)Microsoft Visual Studio 10.0VCbinamd64 that contains [2]:

   CALL "C:Program FilesMicrosoft SDKsWindowsv7.1BinSetEnv.cmd" /x64
   

   If you don’t do this you’re going to get a mind-boggling error like this:

   Installing collected packages: whatever
     Running setup.py develop for whatever
       building 'whatever.cext' extension
   
   Traceback (most recent call last):
     File "<string>", line 1, in <module>
     File "C:/whateversetup.py", line 112, in <module>
       for root, _, _ in os.walk("src")
     File "c:python34Libdistutilscore.py", line 148, in setup
       dist.run_commands()
     File "c:python34Libdistutilsdist.py", line 955, in run_commands
       self.run_command(cmd)
     File "c:python34Libdistutilsdist.py", line 974, in run_command
       cmd_obj.run()
     File "C:whatever.tox3.4libsite-packagessetuptoolscommanddevelop.py", line 32, in run
       self.install_for_development()
     File "C:whatever.tox3.4libsite-packagessetuptoolscommanddevelop.py", line 117, in install_for_development
       self.run_command('build_ext')
     File "c:python34Libdistutilscmd.py", line 313, in run_command
       self.distribution.run_command(command)
     File "c:python34Libdistutilsdist.py", line 974, in run_command
       cmd_obj.run()
     File "C:/whateversetup.py", line 32, in run
       build_ext.run(self)
     File "C:whatever.tox3.4libsite-packagessetuptoolscommandbuild_ext.py", line 54, in run
       _build_ext.run(self)
     File "c:python34Libdistutilscommandbuild_ext.py", line 339, in run
       self.build_extensions()
     File "c:python34Libdistutilscommandbuild_ext.py", line 448, in build_extensions
       self.build_extension(ext)
     File "C:/whateversetup.py", line 39, in build_extension
       build_ext.build_extension(self, ext)
     File "C:whatever.tox3.4libsite-packagessetuptoolscommandbuild_ext.py", line 187, in build_extension
       _build_ext.build_extension(self, ext)
     File "c:python34Libdistutilscommandbuild_ext.py", line 503, in build_extension
       depends=ext.depends)
     File "c:python34Libdistutilsmsvc9compiler.py", line 460, in compile
       self.initialize()
     File "c:python34Libdistutilsmsvc9compiler.py", line 371, in initialize
       vc_env = query_vcvarsall(VERSION, plat_spec)
     File "C:whatever.tox3.4libsite-packagessetuptoolsmsvc9_support.py", line 52, in query_vcvarsall
       return unpatched['query_vcvarsall'](version, *args, **kwargs)
     File "c:python34Libdistutilsmsvc9compiler.py", line 287, in query_vcvarsall
       raise ValueError(str(list(result.keys())))
   ValueError: ['path']
   Complete output from command C:whatever.tox3.4Scriptspython.exe -c "import setuptools, tokenize; __file__='C:/whatever\setup.py'; exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('rn', 'n'), __file__, 'exec'))" develop --no-deps:
   

   msvc9_support.py will run vcvarsall.bat amd64:

   c:Program Files (x86)Microsoft Visual Studio 10.0VC>vcvarsall.bat amd64
   The specified configuration type is missing.  The tools for the
   configuration might not be installed.
   

   Basically that is caused by vcvarsall.bat not being able to run vcvar64.bat because, surprise, the Windows SDK is missing that file.

5. Now everything should work, go and try py -3 setup.py clean —all build_ext —force.

6. Install Microsoft Visual Studio 2010 Service Pack 1 (download). This is optional, however, if you do this you also have to do the following too [3]:

7. Install Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1 (download).

8. Remove all those SQL Server packages that you don’t need from Control PanelPrograms and Features.

Alternative: Victor Stinner argues that just installing the Windows SDKs (v7.0 for Python 2.7, v7.1 for Python 3.3 and 3.4) is enough if you prepare the environment (inconvenient in my opinion):

setenv /x64 /release
set MSSDK=1
set DISTUTILS_USE_SDK=1

See his notes or the Python wiki. You still need to install those fiddly SDKs

For Python 3.5 *

It seems Visual Studio 2015 Community Edition just works without any fuss. Get it here. It’s quite big and doesn’t let you skip the irrelevant SQL Server and .NET tools so I had to manually remove them from Control PanelPrograms and Features.

Alternative: Get the Visual C++ 2015 Build Tools instead. It doesn’t come with Visual Studio and all the useless cruft but make sure you select the Windows 8.1 SDK during the install.

On Ubuntu 14.04, I use Pycharm Professional Edition. When I start a debug session, I see the following message in the event log of Pycharm:

Python Debugger Extension Available

Cython extension speeds up Python debugging

Install How does it work

Clicking on Install leads to a popup window with an error message:

I depict here the text, too, so that it can be found by others more easily:

Compile Cython Extensions Error

Non-zero exit code (1):

unable to execute ‘gcc’: No such file or directory

error: command ‘gcc’ failed with exit status 1

To look for a solution:

1. I compiled Cython speedups manually according to the link mentioned above: /usr/bin/python3 /<PYCHARM_INSTALLATION_PATH>/helpers/pydev/setup_cython.py build_ext --inplace. This finishes successfully, but does not help with the error message.

2. I added the python-3.6-dev repository:
   sudo add-apt-repository ppa:deadsnakes/ppa, executed: sudo apt-get update && sudo apt-get dist-upgrade
   and installed python-3.6-dev: sudo apt-get install python3.6-dev

   It finishes successfully, but does not change the above popup error message.

What else can I check or execute?

EDIT
regarding the installation of gcc, it looks like the following:

user@user-computer:~$ gcc
The program 'gcc' is currently not installed. You can install it by typing:
sudo apt-get install gcc
user@user-computer:~$ sudo apt-get install gcc
[sudo] password for user: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
gcc is already the newest version.
The following packages were automatically installed and are no longer required:
  libseccomp2 libwireshark5 libwiretap4 libwsutil4
  linux-image-3.13.0-160-generic linux-image-extra-3.13.0-160-generic
  linux-lts-xenial-tools-4.4.0-137 linux-signed-image-4.4.0-137-generic
  linux-tools-4.4.0-137-generic squashfs-tools
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
user@user-computer:~$ gcc
The program 'gcc' is currently not installed. You can install it by typing:
sudo apt-get install gcc