[Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.

[Luke Kenneth Casson Leighton]

> On Sun, Jan 25, 2009 at 9:01 AM, Matthieu Brucher
>  <matthieu.brucher at gmail.com> wrote:
> > 2009/1/25 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
> >> according to the wikipedia entry on dlls, dlls do not support data,
> >> only functions.
> >
> > What do you mean by "not support data"? Having global data variables in a dll?
> > In wikipedia, it is explicitely told that this is possible to have
> > data (http://en.wikipedia.org/wiki/Dynamic-link_library). Without
> > them, shared library cannot be used.

matthieu, thank you for responding.  from
http://en.wikipedia.org/wiki/Dynamic-link_library:

"Third, dynamic linking is inherently the wrong model for paged memory
managed systems. Such systems work best with the idea that code is
invariant from the time of assembly/compilation on.
........... Data references do not need to be so vectored because
 DLLs do not share data."
^^^^^^^^^^^^^^^^^^^^

does anyone happen to know what this means?

also, what do you mean by "without data, shared library cannot be
used"?  you can _always_ call a function which returns a pointer to
the data, rather than access the data directly.


> Indeed.  That's why the header files contain
> define PyAPI_DATA(RTYPE) extern __declspec(dllexport) RTYPE
> define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE

curt, thank you for responding.  i'd seen this: i understood it -
and... yet... mingw happily segfaults when asked to access _any_ data
in _any_ object file of the python2N dll.

Py_NoneStruct, PyExc_* (of which there are about 50), Py*_Type - all of them.

solutions so far involve ensuring that anything declared with
PyAPI_DATA is *NEVER* accessed [across a dll boundary] - by for
example moving the module into python2N.dll.

also, yes i had looked up how to do .def files, and how
__declspec(dllexport) etc. work.  of all the examples that you find
about dlltool, mingw, dlls, defs, etc. they _all_ say "function."  to
declare a _function_ you do X, Y and Z.  not one of them says "to
place data in a dll, you do X Y and Z".

then, looking at the wine dlls and .defs, i haven't yet found a
_single_ one which returns data - they're _all_ functions (from
looking so far. e.g. i expected MSVCRT.DLL errno to be an int - it's
not: it's a function).

*sigh*.  if this turns out to be yet another gcc / mingw bug i'm going
to be slightly annoyed.  only slightly, because this _is_ free
software, after all :)

l.