[Python-Dev] Re: Switching to VC.NET 2003

[Phillip J. Eby]

At 02:57 PM 1/4/04 +0000, Paul Moore wrote:
>I have a patch which seems to do the right thing with respect to
>adding "-lmsvcr71" to the GCC link command.
>
>The resulting build looks OK, and building a simple extension works
>fine. Apparently, however, Phillip J. Eby got a working DLL without
>needing this. And indeed I have no problems omitting the -lmsvcr71. So
>we don't have a real example of the "potential issue" with mismatched
>MSVC runtimes. Nevertheless, if you do "objdump -p myext.pyd" and look

Aha, so *that*'s the option I needed ("private headers" didn't look like 
something to do with dependencies).  Dumping my kjbuckets.pyd, I got:

  DLL Name: msvcrt.dll
  vma:  Hint/Ord Member-Name Bound-To
  c1f8       36  __dllonexit
  c208      147  _errno
  c214      510  abort
  c21c      522  calloc
  c228      537  fflush
  c234      547  fputc
  c23c      552  free
  c244      560  fwrite
  c250      603  malloc
  c25c      636  sprintf

I didn't think kjbuckets used that many C functions.  Apparently there are 
lots of debugging prints.  protocols/_speedupds.pyd had much fewer:

DLL Name: msvcrt.dll
vma:  Hint/Ord Member-Name Bound-To
9258       36  __dllonexit
9268      147  _errno
9274      510  abort
927c      537  fflush
9288      552  free
9290      603  malloc

and ZODB 4's _persistence.pyd has:

DLL Name: msvcrt.dll
vma:  Hint/Ord Member-Name Bound-To
6200       36  __dllonexit
6210      108  _assert
621c      147  _errno
6228      510  abort
6230      537  fflush
623c      552  free
6244      603  malloc
6250      666  time

So it really does appear that the mscvcr71 linkage would be a very good idea.


>at the import tables, you do see that runtime symbols are satisfied
>from msvcrt without the -l flag, and from msvcr71 with it (apart from
>abort, which is always from msvcrt, which seems to be a peculiarity of
>how the mingw startup code is linked).

Do you think that's likely to cause any issues?