[Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken

[noreply@sourceforge.net]

Bugs item #558488, was opened at 2002-05-21 10:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 10:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-06 09:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 05:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470