After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728079 - build problem: DL_EXPORT and python 3.3
build problem: DL_EXPORT and python 3.3
Status: RESOLVED DUPLICATE of bug 679438
Product: gobject-introspection
Classification: Platform
Component: general
2.40.x
Other All
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-04-12 09:38 UTC by Patrick Welche
Modified: 2015-02-07 16:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Patrick Welche 2014-04-12 09:38:47 UTC
giscanner/giscannermodule.c declares

DL_EXPORT(void)
init_giscanner(void)

There is no longer any trace of DL_EXPORT in python 3.3's header files.
(Its days were numbered since http://bugs.python.org/issue566100)

The alternatives (which exist at least in python 2.7) are:

  PyAPI_FUNC(type): Declares a public Python API function and return type
  PyAPI_DATA(type): Declares public Python data and its type
  PyMODINIT_FUNC:   A Python module init function.  If these functions are
                    inside the Python core, they are private to the core.
                    If in an extension module, it may be declared with
                    external linkage depending on the platform.

It looks as though PyMODINIT_FUNC would be suitable?
Comment 1 Patrick Welche 2014-04-12 09:41:25 UTC
Hmmm or PyAPI_FUNC()? (Now you see why I didn't just write the patch)
Comment 2 Patrick Welche 2014-04-12 09:48:31 UTC
PyAPI_FUNC, as PyMODINIT_FUNC would imply that it returns a PyObject*

but after that change (git-head):

../giscanner/giscannermodule.c:63:9: error: 'PyTypeObject' has no member named 'ob_type'
     type.ob_type = &PyType_Type;              \
Comment 3 Simon Feltman 2014-04-13 23:17:17 UTC
Take a look at:
https://docs.python.org/3/howto/cporting.html#module-initialization-and-state

We use a Python 2/3 API shim in PyGI to deal with some of this stuff:
https://git.gnome.org/browse/pygobject/tree/gi/pyglib-python-compat.h
Comment 4 Simon Feltman 2014-04-15 02:28:06 UTC
I ran into the same build error today while mistakenly trying build from a jhbuild where PYTHON=python3.3. I needed to run distclean to get it fixed up again.

Was this ticket intended as part of a general porting effort for gobject-introspection to Python 3 or is it possibly due to something like PYTHON being set to Python 3?

Note there is also bug 679438 for tracking a Python 3 port.
Comment 5 Patrick Welche 2014-04-15 07:31:58 UTC
I didn't realise that it is the beginning of a port(!) I had searched for DL_EXPORT and nothing turned up. Mark as a duplicate for python 3 porting, or leave as the first problem one encounters when trying to build with python 3?
Comment 6 Simon Feltman 2014-04-20 23:05:16 UTC
(In reply to comment #5)
> ... Mark as a duplicate for python 3 porting, or
> leave as the first problem one encounters when trying to build with python 3?

Personally I would probably maintain a patch set on a single ticket for the porting effort. But if you are interested in working on this, it is up to you.
Comment 7 Simon Feltman 2014-05-02 04:14:10 UTC

*** This bug has been marked as a duplicate of bug 679438 ***
Comment 8 André Klapper 2015-02-07 16:49:22 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]