[Python-Dev] The other Py2.4 issue

[Paul Moore]

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___Py_NoneStruct. 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.