[Python-Dev] Static builds on Windows

[Nick Coghlan]

Martin v. Löwis wrote:
> Nick Coghlan wrote:
> 
>> If there was going to be both the ability to create a static lib and a 
>> dynamic lib, it would seem to make more sense to have the project for 
>> the dynamic lib project simply incorporate the static lib, and export 
>> the relevant symbols.
> 
> Does that actually work? Doesn't the compiler generate different code
> depending on whether the code is going to be in a static vs. dynamic
> library?

Well, it works for us in VC6. However, I believe the way it is done is 
that the static library projects all define the relevant EXPORT_DLL 
macro. (I'd have to check to be certain, but I won't be back at work 
until October)

And it now occurs to me that we've never tried bypassing the main DLL 
completely, and incorporated the static libraries directly into an 
executable program.

(This part of the program has been stable for so long, it's been a 
couple of years since I've had to think about it!)

> If you can provide a patch to the project files which makes it happen
> for the VC7 projects, I would be very much in favour of including it
> (provided it can be demonstrated that it does actually work, and does
> not cause much overhead beyond the additional static library that is
> going to be generated).

Unfortunately, I don't have access to VC7, even at work - hence the fun 
and games trying to get the free toolkits to cooperate ;)

> Also, there is the issue of what C runtime to chose: should that be
> the static CRT, or a dynmaic one? Clearly, for the DLL, we need the
> dynamic CRT, but for the static python.lib, we might need a static
> CRT instead.

Ouch - OK, that one could be a problem. We link to the dynamic CRT for 
everything - we discovered the hard way that linking a '.lib' to the 
static CRT caused grief whenever we tried to use that library. Since our 
executable would be linking to a *different* CRT from the one the 
library was using, the only way it could work was by ensuring that any 
memory allocated by a particular library was freed by that library. And 
that's a restriction we weren't prepared to apply to the sub-libraries 
(we do apply it at DLL boundaries, though).

Regards,
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan at email.com  | Mobile: +61 409 573 268