I have used the Python 2.4.2 source to create a static
linkable version under windows (.lib). The executables
using that library fail to find the registry path of an
already existing Python 2.4 installation.

I have traced this down to the PC/dl_nt.c file, where
the variable PyWin_DLLVersionString is defined, but not
initialized, execpt if the DllMain function is called.
That function is only called by a process loading a
DLL, this is not the case with an static linked library.

I have used a preprocessor check against
Py_NO_ENABLE_SHARED to create a modified version of
dl_nt.c that will initialize the variable and remove
the DLLMain function from the static version (and keep
the original code when making a shared DLL)

With this minimal modification "import site" works as
usual even in an static linked version.

For your convenience the modified file can be found in
the attachement.

Logged In: YES 
user_id=1188172

What does the Windows expert say?

Do we want to support this? What is the use of a static build?

I think it would be nice to support it, atleast in the C files (not
necessarily, but possibly, in the project files as well).

The point of a static Python library is that you can embed it into an
application without requiring an additional DLL. That also allows you to
leave out modules that you don't need at link time. Combine this with
freeze, and you can embed an application without any additional files to
be shipped. Without embedding, but with freeze, you get true standalone
binaries (as opposed to py2exe-fake-I-silently-extract-at-run-time
standalone binaries)