We Keep Coding

Manually update the openssl version used by python on windows x64

I am running python 3.9.1 for windows 10 (x64). I have noticed the openssl dll files shipped with python (libcrypto-1_1.dll & libssl-1_1.dll) are only version 1.1.1.7. I would therefore like to replace these with the latest versions.
I have been able to successfully build openssl 1.1.1.9 in windows 10 following the instructions in the release. I am using Microsoft visual studio 2019 + strawberry perl + nasm. I ran the following config command using the x64 native tools command prompt for vs 2019:
perl Configure VC-WIN64A
I then run the nmake command. This produces the two dlls I need: libcrypto-1_1-x64.dll and libssl-1_1-x64.dll
I renamed both files to remove the "-x64" at the end of the name and then used them to replace the existing dlls in the python installation.
When I try to import the ssl library in python, I get the error:
ImportError: DLL load failed while importing _ssl: The specified module could not be found.
I then built openssl for x86, using the x86 native tools command prompt for vs 2019 and the command:
perl Configure VC-WIN32
I then ran nmake which produced: libcrypto-1_1.dll and libssl-1_1.dll
I replaced the dlls in the python installation with those. When I try and import the ssl library in python I get:
ImportError: DLL load failed while importing _ssl: %1 is not a valid Win32 application.
I am reasonably certain I need the x64 version of the dlls because (1) my python installation is x64 (2) when I used the visual studio dumpbin.exe tool on the python shipped dlls to inspect the headers they say "x64" in them (3) the x64 dlls are a similar size to the ones shipped with python and the x86 versions are smaller.
I was once able to do this following the above steps for an older version of python. That version shipped with openssl 1.1.3 (could be 4) and I built the dlls for 1.1.6 (could be 7) and replaced them and python had no issues. Is it possible that the default configuration scripts have changed over these versions such that the default windows x64 configuration no longer builds openssl in a way that works with python and I therefore need to use custom settings?
I think the info at section 1.3 of this page may be relevant, but if it is I am not sure how to implement that in the openssl build process.

I managed to solve this with some help.
The scripts used by CPython to build OpenSSL for the windows installers actually run the command:
Perl Configure VC-WIN64A-masm no-asm
instead of
Perl Configure VC-WIN64A
After running the correct command on the setup described in my original post I was able to swap out the dlls and python accepted them without issue.
ssl.OPENSSL_VERSION now outputs ‘OpenSSL 1.1.1i 8 Dec 2020’.

Cmake GUI could not find boost (missing: system python3) (found version "1.72.0"), on Windows 10

I am trying to install PyOpenPose on Windows 10, using Cmake GUI. It requires OpenCV so I downloaded the prebuild OpenCV for Windows. Then I cmake the repository, import the OpenCV directory, everything is ok, until it required Boost. I downloaded the latest Boost version 1.72.0 and copy it to C:\boost\boost_1_72_0, since the installation manual tells me to do that to get CMake to detect the Boost. But its detection was like this:
By reading it I guessed Cmake has detected the Boost but it could not detect the python, the missing is system python3 and the Boost 1.72.0 has been found. So I add a DPYTHON_EXECUTABLE and set its path to C:\Users\abc\AppData\Local\Programs\Python\Python38\python.exe but the problem still remains.
Those DBOOST_LIBRARYDIR and DBOOST_ROOT were added by me. Cmake exports the same errors even without those arguments.
So that I am stuck here.

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\

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

Finding the correct Python framework with cmake

I am using the macports version of python on a Snow Leopard computer, and using cmake to build a cross-platform extension to it. I search for the python interpreter and libraries on the system using the following commands in CMakeLists.txt
include(FindPythonInterp)
include(FindPythonLibs )
However, while cmake identified the correct interpreter in /opt/local/bin, it tries to link against the wrong framework - namely the system Python framework.
-- Found PythonInterp: /opt/local/bin/python2.6
-- Found PythonLibs: -framework Python
And this causes the following runtime error
Fatal Python error: Interpreter not initialized (version mismatch?)
As soon as I replace -framework Python with /opt/local/Library/Frameworks/Python.framework/Python things seem to work as expected.
How can I make cmake link against the correct Python framework found in
/opt/local/Library/Frameworks/Python.framework/Python
rather than the system one in
/System/Library/Frameworks/Python.framework/Python
?

Adding the following in ~/.bash_profile
export DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks
fixes the problem at least temporarily. Apparently, this inconsistency between the python interpreter and the python framework used by cmake is a bug that should be hopefully fixed in the new version.

I am not intimately familiar with CMake, but with the Apple version of gcc/ld, you can pass the -F flag to specify a new framework search path. For example, -F/opt/local/Library/Frameworks will search in MacPorts' frameworks directory. If you can specify such a flag using CMake, it may solve your problem.