We Keep Coding

How do I build a C Python Extension for Windows using Cygwin64?

To preface: my code works as I expect when compiling and running on Linux. However, this library needs to be compiled for use on a Windows machine. I looked in to a couple different options, and decided that using Cygwin to compile for Windows seemed to be the correct choice. I'm using a setup.py file with the distutils.core library and compiling using python setup.py install. When compiling on Windows in Cygwin, it fails to find pthread.h, arpa/inet.h, netinet/in.h, and sys/socket.h. I was under the impression that Cygwin came prepackaged with these headers, which is why I chose to use it. The alternative to Cygwin is putting preprocessor commands everywhere and using Windows specific libraries such as winsock2.h, which I want to avoid if at all possible. Is it possible to compile for Windows using Cygwin? If so, what have I done wrong to cause Cygwin to not recognize these headers?

You need to install the proper headers
$ cygcheck -p usr/include/pthread.h
Found 9 matches for usr/include/pthread.h
cygwin-devel-3.0.7-1 - cygwin-devel: Core development files
..
cygwin-devel-3.1.6-1 - cygwin-devel: Core development files
...
so install the cygwin-devel package
To check all the shared libraries needed by the built dll, you can use cygcheck
$ cygcheck /usr/lib/python3.8/site-packages/Cython/Compiler/FlowControl.cpython-38-x86_64-cygwin.dll
D:\cygwin64\lib\python3.8\site-packages\Cython\Compiler\FlowControl.cpython-38-x86_64-cygwin.
dll
D:\cygwin64\bin\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
D:\cygwin64\bin\libpython3.8.dll
D:\cygwin64\bin\cygintl-8.dll
D:\cygwin64\bin\cygiconv-2.dll
D:\cygwin64\bin\cyggcc_s-seh-1.dll
As was built with Cygwin Python, you need also to transfer the cygwin python...

Most important, I think, is to follow the instructions in the Python help or on the Python doc web site for "Extending and Embedding the Python Interpreter" for the version you are building the extension for. For windows, the build instructions identify the build environment used to create the binary package that you download from python.org, usually something like VS2013 or VS2017. (As an aside, I think the Community editions have everything you need, and I don't think you actually have to use the Visual Studio GUI when you build using nmake from the CMD.EXE terminal.)
To build in Cygwin for use in a Windows version of Python, you may need to install and then use the x86_64-w64-mingw32-gcc, etc., cygwin packages to cross-compile non-cygwin (i.e. pure windows) executables and DLLs from Cygwin.
Binary extensions must be built using the source tree for a specific Python major.minor version, and bitness. For windows, you will need to build multiple versions of the extension, one for each major.minor, bitness version of Python that will import it, e.g. 3.6, 3.7, 3.8, 3.9, 32-bit, 64-bit. The extension code may not require changes between versions, but it still needs to be compiled with the right compiler and linked against exactly the same shared libraries (in this case .DLL files) as used by the Python executable. For instance, it must use exactly the same version of Microsoft's C run time library DLL as the Python executable does. This is a bit more sensitive and restrictive than on Linux, where you can rebuild the python executable and your extension with the same toolchain from your distro more easily.

OpenNERO windows: Could not find the following Boost libraries: boost_python

I am trying to run OpenNERO on my Windows 10. I had installed all the dependencies mentioned on their wiki for building it. My Python version is 2.7.15
(have tried with Python 2.7, and latest 3.7.1 as well), boost version is 1.58 (have tried 1.66 and 1.53 as well).
I went to my boost folder location: "C:\Program Files\boost\boost_1_67_0", and opened the command prompt as an administrator in that location, and then followed the instructions to build boost.
I ran the bootstrap.bat file in the cmd, output shown below:
Then I ran the .\b2 --build-type=complete -j2 command which ran for a couple of hours and the short output is shown in this pastebin.
Following this I went to Cmake and tried to build the project which gave me following errors:
Could NOT find Boost
Boost version: 1.67.0
Boost include path: C:/Program Files/boost/boost_1_67_0
Could not find the following Boost libraries:
boost_python
Some (but not all) of the required Boost libraries were found. You may
need to install these additional Boost libraries. Alternatively, set
BOOST_LIBRARYDIR to the directory containing Boost libraries or
BOOST_ROOT to the location of Boost.
CMake Error at source/CMakeLists.txt:33 (MESSAGE):
Boost libraries were not found, please install from
http://www.boost.org/
I have all the boost-python files in my stage/libs folder as shown below then why is it giving me this error?
My environment variables are also correctly set-up as shown below:

Changed the line 26 in this cmake file from FIND_PACKAGE (Boost COMPONENTS python filesystem serialization system date_time) to FIND_PACKAGE (Boost COMPONENTS python27 filesystem serialization system date_time) so that it looks for python27 instead of python. Also used the 64bit generator in cmake gui instead of the 32 bit one.

Error during: CREATE EXTENSION plpython3u; on PostgreSQL 9.6.0

I have installed PostgreSQL Server 9.6.0 and Python 3.4.2 on Windows 2012 R2 Server.
I copied plpython3.dll to C:/Program Files/PostgreSQL/9.6/lib/
The in PostgreSQL I try running this command: CREATE EXTENSION plpython3u;
And I receive this message:
ERROR: could not load library "C:/Program Files/PostgreSQL/9.6/lib/plpython3.dll": The specified module could not be found.
Under this folder: C:\Program Files\PostgreSQL\9.6\share\extension there are plpython3u files.
How can I get PostgreSQL to recognize this Python 3 extension?
Thanks!

Copy the python34.dll file to c:\windows\system32 and name the copy python33.dll
The create language plpython3u should then work without a problem.

Exactly the same situation I faced with Postgres 9.6 Windows 10.
PL/Python3U would not get through.
Worked around it:
Installed Python34 64bit Windows 10 version.
Copied Python34.dll to c:\windows\system32 as Python33.dll and it worked.

The information is in Makefile of source installation package
We need libpython as a shared library. In Python >=2.5, configure asks Python directly. But because this has been broken in Debian for a long time (http://bugs.debian.org/695979), and to support older Python versions, we see if there is a file that is named like a shared library as a fallback.
for python windows:
ifeq ($(PORTNAME), win32)
pytverstr=$(subst .,,${python_version})
PYTHONDLL=$(subst \,/,$(WINDIR))/system32/python${pytverstr}.dll
So the write answer is:
WINDIR is : C:\Windows
pytverstr is use in makefile has a parameter to define version of python
PYTHONDLL is the location of dll
To check version of my installation, I open plpython3.dll located in C:\Program Files\PostgreSQL\9.4\lib (change path with your environnement)
With Notepad++ and search PyUnicode_AsUTF8String
the python dll version is visible in last word (in my case python33.dll)
check your installation to choice the good installer of python
SELECT version();
PostgreSQL 9.4.15, compiled by Visual C++ build 1800, 64-bit
So I need install Python 33 in 64bit
edit 2020-10-02
There is also all of these informations in doc of binary ..pgsql\doc\installation-notes.html look at title Procedural Languages
edit 2021-06-11
After install the good version of Python on your system you need copy it to C:\Windows\System32
Replacing the version of python with an old name is not a good solution because you can have librairie it not work with this version. Do that if you know risks. So if you want a newest version of python for plpython, compile it or check edb compilation to check if it contains what you need. You can ask EDB for this information.

plpython3.dll in the official package is built against python 3.3, not python 3.4. What it expect is python33.dll in system32 folder. You need to install python 3.3 for your system.
Since py33 has been phased out, you may soon get frustrated, due to lack of pre-built binary package, lxml, pyzmq etc all needs to be built from source. If you need any binary module, make sure you have a correctly set up compiler.

This may be helpful, I have struggled a lot with this. For me only worked when I installed the right version of python and added paths to environment variables. I am not sure if python 3.4.0 would be the right version for PostgreSQL Server 9.6.0 but it worked fine with PostgreSQL Server 10.0.
Try version python-3.4.0.amd64 for windows 64bit or other versions from this Python 3.4.0 downloads Link
Environment variables to add:
C:\Python34\Scripts
C:\Python34\

Why Cython extensions on Windows depend on pythonXX.dll but not on MacOSX?

I built the same libraries ( example below is from rfoo ) on windows and mac, and the mac version only has system dependencies
$ otool -L marsh.so
marsh.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
while on windows it depends on python's dll
>dumpbin /dependents marsh.pyd
Microsoft (R) COFF/PE Dumper Version 12.00.31101.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file marsh.pyd
File Type: DLL
Image has the following dependencies:
python25.dll
MSVCR120.dll
KERNEL32.dll
I wonder if it's an implementation choice that is not really due to windows, or if there is something specific to windows that requires this.
Context: I use this to load python extensions from within an embed interpreter inside Ableton Live, which uses an old python version ; but the worst is that python is not loaded as a library, it's statically linked inside the software. On mac, it's not a problem, I can still load the extension. On windows, I can't, because I have to link to python25.dll, but then at load it tries to initialize again the interpreter, which gives an error, since the dll is not used by Ableton Live. I wonder if there is some hope to have it work on windows.

There are DLL on OS X and as opposed to Windows, most OS X applications are statically linked, bigger but with less external dependencies.

Installing pymatbridge on Windows

In version 0.3 of pymatbridge, an additional dependency was added for ZMQ. To install this version, you might therefore need to compile a messenger mex extension linking against a dll of zeromq. However, this turns out to be rather difficult to do in some cases.
Does anyone have examples of success stories installing pymatbridge from source on a machine running Windows?

Here's my setup and build instructions; apologies for the verbosity -- this is from a write-up I did for my lab notebook.
Specifications:
Windows 8.1 (64 bit)
Anaconda 1.9.1
python 2.7.6
MinGW
TDM GCC 4.8.1
First I installed MS Visual C++ & SDK 7.1. Possible reason for the install to fail quite early on is the presence of other Visual C++ compiler versions and/or SDKs -- before successfully installing SDK 7.1 I had to uninstall quite a few of them.
First, using the Windows SDK 7.1 Command Prompt, I
mex -setup
and selected the newly installed compiler. In my case
Select a compiler:
[1] Microsoft Software Development Kit (SDK) 7.1 in
C:\Program Files (x86)\Microsoft Visual Studio 10.0
[0] None
Compiler:
I elected to pick number 1.
Next I downloaded and installed a prebuilt 64 bit ZMQ 3.2.4, and from the ZMQ 3.2.4 install location, C:\Program Files\ZeroMQ 3.2.4\lib, I copied libzmq-v90-mt_3_2_4.lib, and libzmq-v90-mt_3_2_4.dll from C:\Program Files\ZeroMQ 3.2.4\bin to the messenger build directory, ~\python-matlab-bridge\messenger\src.
I also put zmq.h and zmq_utils.h into that directory but as of now am unsure if they are really necessary.
Then, in the Windows SDK 7.1 Command Prompt, I cded into the messenger\src directory and issued
mex messenger.c libzmq-v90-mt-3_2_4.lib -O -output messenger
to obtain a messenger.mexw64.
Finally, in the ~\python-matlab-bridge directory, using MinGW, I just
python setup.py install
This automatically put the built package into my Anaconda\Lib\site-packages along with an egg info. In Anaconda\Lib\site-packages\pymatbridge\matlab there is the messenger.mexw64 that was built earlier -- from ~\python-matlab-bridge\messenger\src.
I also copied to Anaconda\Lib\site-packages\pymatbridge\matlab all other .dlls, .libs and .hs for good measure.
Now in the iPython 2.7 console, or an iPython Notebook, I can
%load_ext pymatbridge
successfully.

As I use Visual Studio as my standard IDE I fiddled around and got a working build process.
I used:
VS 2013
Matlab 2013b x64
Python 3.3 x64
ZeroMQ 4.0.4.
If you use different Versions please make sure that you adjust the Path where necessary.
Build messenger using Visual Studio (2013)
First create a new Solution with an empty C++ Project.
Set up the configuration, e.g. x64
Release
Open up the Project Properties and set up the following:
Configuartion Properties -> General:
Target Name: messenger
Target Extension: .mexw64
Configuration Type: Dynamic Library (.dll)
Configuartion Properties -> VC++ Directories -> Include Directories:
MATLABPATH \extern\include
ZEROMQ PATH\include
Configuartion Properties -> VC++ Directories -> Library Directories:
MATLABPATH \extern\lib\win64\microsoft
ZEROMQ PATH \lib
Configuartion Properties -> Linker -> Input -> Additional Dependencies:
libmx.lib; libmex.lib; libmat.lib; libzmq-v120-mt-4_0_4.dll
Configuartion Properties -> Linker ->Command Line -> Additional Options:
/export:mexFunction
Add messenger.c as source file
Build the library
Copy it to: PYTHONPATH \Lib\site-packages\pymatbridge\matlab\
Please Note:
I got some incompatible error cause by the function names already present in windows.h.
The solution was to rename:
initialize
listen
respond
cleanup
to:
initializeMat
listenMat
respondMat
cleanupMat

Some of the other answers are a little bit outdated, and this can be done much more easily now (still won't be as easy on a Linux system :/). First of all, pymatbridge now includes a binary mex on Windows which is statically linked to libzmq, so you shouldn't actually have to compile anything to get it to work.
However, if you still want to do compile it from source, the process isn't too bad for a dynamically linked library.
1) Install zeromq from the website: http://zeromq.org/distro:microsoft-windows
2) Rename one of the lib/libzmq-*.lib files to libzmq.lib in the ZeroMQ installation directory
3) Add the ZeroMQ bin directory to your path.
4) Edit the messenger/mexw64/local.cfg file in messenger to point to the zeromq install directory (you will need to update both ZMQ_INC and ZMQ_LIB). Also ensure the MATLAB directory is correct.
5) Run make.py matlab in the messenger directory. This should build messenger.mexw64
A statically linked library is simple in practice, but because zeromq (as of now) does not provide a .lib for static linking with the windows installer, you will need to compile this yourself. After you have a static .lib, build messenger.mexw64 with make matlab --static