[Python-Dev] The other Py2.4 issue (original) (raw)

Paul Moore p.f.moore at gmail.com
Fri Dec 10 23:20:29 CET 2004

On Fri, 10 Dec 2004 20:40:10 +0000, Paul Moore <p.f.moore at gmail.com> wrote:

On Fri, 10 Dec 2004 17:19:21 +0000, Armin Rigo <arigo at tunes.org> wrote: > Another note: can you report on whether building libpython24.a can be skipped > for mingw?

A first attempt seems to almost work. There is a problem with structures, however - I get an error about unresolved references to imp_PyNoneStruct. My guess is that there's some issue with resolving references to data (as opposed to functions) from DLLs. I'll investigate further and then report back.

OK. After some more extensive investigation:

  1. You cannot use python24.lib (ie, skip building libpython24.a). If you do, data values exported from python24.dll (specifically, Py_NoneStruct, which is quite important :-)) do not get exported correctly. I don't know exactly why - I guess it's something to do with how the MS LIB format works.

  2. You can, however, link direct to python24.dll, which works fine. Unfortunately, there are 2 problems with this - first, distutils doesn't support it as things stand, and second, it isn't possible to get the full path of the Python DLL without using Mark Hammond's pywin32, or custom C code :-( (You need to get from sys.dllhandle to the filename, and the API to do this isn't exposed).

  3. In some cases, an extension built with mingw still contains references to msvcrt (I think Martin has noted this). This seems not to be an issue. What is happening, is that any symbols referenced from user code are satisfied from msvcr71, and so match the Python DLL. However, if the mingw startup code uses symbols which have not been satisfied by the time all references from user code are resolved, then these references are satisfied from msvcrt. But I can't see any way that these references are going to do any harm, as they are startup code, which by its nature will have been written to work cleanly in this situation (linking like this is explicitly supported by mingw). Martin, as the CRT compatibility expert, does this sound reasonable? The mingw people certainly seem to think that the situation is OK...

You could probably incorporate Philip Eby's script, posted here a while ago, which he mentioned earlier in this thread, into a setup.py so that if libpython24.a didn't already exist, the setup script would build it. This would give you a reasonably clean way of making sure it was present. Philip's script doesn't need anything but mingw installed, AIUI.

Longer term, I'll see if I can put together a distutils patch to make it reference pythonXX.dll directly, so removing the need for libpythonXX.a in the future. Obviously, this is only going to be relevant for Python 2.5 and later, though.

Sorry for the long mail, but I thought it would be useful to get the details in the archives...

Paul.

More information about the Python-Dev mailing list