Tim Peters writes:
Somebody recently added DL_IMPORT macros to two module init functions that already used their names in DL_EXPORT macros (pyexpat.c and parsermodule.c).
That was me.
On Windows, that yields the result I (naively?) expected: compiler warnings about inconsistent linkage declarations.
Ouch.
This is your basic Undocumented X-Platform Macro Hell, and I suppose the Windows build should be #define'ing USE_DL_EXPORT for these subprojects anyway (?), but if I don't hear a good reason for *why* both macros are used on the same name in the same file, I'll be irresistibly tempted to just delete the new DL_IMPORT lines. That is, why would we *ever* use DL_IMPORT on the name of a module init function? They only exist to be exported.
Here's how I arrived at it, but appearantly this doesn't make sense, because Windows has too many linkage options. ;) Compiling with gcc using the -Wmissing-prototypes option causes a warning to be printed if there isn't a prototype at all: cj42289-a(.../linux-beowolf/Modules); gcc -fpic -g -ansi -Wall -Wmissing-prototypes -O2 -I../../Include -I.. -DHAVE_CONFIG_H -c ../../Modules/parsermodule.c ../../Modules/parsermodule.c:2852: warning: no previous prototype for `initparser' I used the DL_IMPORT since that's how all the prototypes in the Python headers are set up. I can either change these to "normal" prototypes (no DL_xxPORT macros), DL_EXPORT prototypes, or remove the prototypes completely, and we'll just have to ignore the warning. If you can write a few sentences explaining each of these macros and when they should be used, I'll make sure they land in the documentation. ;) -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member