[Python-Dev] Static builds on Windows (original) (raw)

Nick Coghlan ncoghlan at iinet.net.au
Thu Jul 29 23:50:40 CEST 2004

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

More information about the Python-Dev mailing list