[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