[Python-Dev] Building Extensions for Python 3.5 on Windows

Steve Dower steve.dower at python.org
Wed Sep 2 20:42:01 CEST 2015


On 02Sep2015 0803, Paul Moore wrote:
> On 2 September 2015 at 14:07, Steve Dower <steve.dower at python.org> wrote:
>> You can also build existing object or static libraries into their own DLL
>> with the old compiler and dynamically link to them. It's not perfect, but
>> it's no worse than trying to link them in directly.
>
> Interesting approach. "gcc -shared -o xpm.dll xpm.a" does about what I
> want. Some thoughts:
>
> 1. This dynamically links to msvcrt.dll. Is that OK? I guess the
> answer is "it's no worse than using such a DLL with Python 3.4 would
> be" :-)

Yeah, "no worse" is the answer here.

> 2. I presumably need an import lib. I can get gcc to generate a .a
> format one, I'll need to see if VC 2015 can handle those, or if
> there's a way to convert them (I'm sure there is, but it's been a long
> time since I had to do that...)

I'm fairly sure there's a dumpbin.exe/lib.exe dance you can do, but it's 
been a long time since I've had to do it too.

> Anyway, thanks for the response.
>
> Just one further question if I may - on going the other way. Is it
> acceptable to embed Python 3.5 (via fully runtime
> LoadLibrary/GetProcAddress calls to load python35.dll) in an
> application that uses an older CRT? My initial instinct is that it
> probably isn't, but I can't think it through - my head's definitely
> hurting by now :-)

The answer is "yes, but", where the but depends on what you're sharing 
between the application and Python. As long as you're careful to let 
Python do its memory management and the app do its own and their paths 
never cross, you'll probably be okay.

Cheers,
Steve

> Paul
>



More information about the Python-Dev mailing list