On Windows, the initfunc of a C extension is exported twice, as
seen here:

test_distutils
xxmodule.c
xxmodule.obj : warning LNK4197: export 'initxx' specified multiple times; using first specification


First export: pyport.h: #define PyMODINIT_FUNC __declspec(dllexport) void

Second export: Specified on the command line with /EXPORT

The code responsible for adding the initfunc name to ext.export_symbols
is in build_ext.py:get_export_symbols. I'm not sure if it could be
removed, since older extensions might not use PyMODINIT_FUNC.

If it can't be removed, perhaps PyMODINIT_FUNC could be specified
simply as void.

Tarek, I forgot to add you, sorry. I was thinking mainly about distutils,
not distutils2.

I can review a patch for this bug but not write it, lacking knowledge in C.

This is the history of the issue:

In r16757 the current version of get_export_symbols() was added to
distutils. This function adds /EXPORT initfunc to the command line.

In 27697 PyMODINIT_FUNC was defined as __declspec(dllexport) void.


I'd suggest to remove get_export_symbols(). This would only affect
extensions that do not use PyMODINIT_FUNC, but that can be easily
repaired.

I don’t think we can remove a method.  Can you make a patch with your other suggestion?  Thanks.

Thinking about it, declaring PyMODINIT_FUNC as void would be a huge
step backwards. Using PyMODINIT_FUNC is the correct way of doing things.
The current situation punishes developers who actually read the docs.

If a C module stops working because of the change, _all_ the maintainer
has to do is change a single line in the sources. PyMODINIT_FUNC is
nearly 10 years old, so I think this is not too much to ask.


May I suggest deprecating get_export_symbols() for these reasons:

  1) The docstring is incorrect: The function does not 'either
     use export_symbols or "PyInit_" + module_name'. It forcibly
     adds PyInit_" + module_name', if it isn't already present in
     export_symbols.

  2) PyMODINIT_FUNC - which is nearly 10 years old - has obsoleted
     this function.

  3) Developers who do the right thing are punished, since they have
     to investigate the warning.



It is also possible to leave the function (see initfunc2.patch). Then
again, on its own get_export_symbols() is practically useless.

The policy for distutils is: no changes, only bug fixes.  We cannot remove a function, even useless.  Deprecating does not seem useful if we aren’t going to remove.  Changing the docstring, the docs or the output of the code is okay.  Therefore, initfunc2.patch is the way to go.  Can you add a test for its behavior?

Without the patch, you see the warning if test_build_ext is run in
verbose mode. With the patch, the warning disappears.

Sounds like a “+1 for the patch” to me :)

I get no warning on linux2 after the patch.  This is still a behavior change, and there might be code out there relying on self.get_export_symbols being called.  My understanding of extension modules build is too small for me to have confidence, so I will defer the decision to Tarek.

Thank you for that patch, Stefan. I am currently tinkering with bringing pycrypto to 3.x and ran into this issue. initfunc2.patch resolves the issue on Win7-64, python31-64.

I don't feel comfortable releasing code that requires the user to manually patch Python to build. What are my options here? Go back to void instead of PyMODINIT_FUNC? Is there aught else I can do to make sure pycrypto will build well "in the wild"?

Thorsten: my recommendation is to ignore this issue in your software. It's just a warning.

A workaround would be to define an arbitrary macro when building with distutils. For example, in setup.cfg:

    [build_ext]
    define = _DISTUTILS

Then in some main header file(s) in your project:

    #ifdef _DISTUTILS
    #undef PyMODINIT_FUNC
    #define PyMODINIT_FUNC void
    #endif

And you won't get the warning anymore.