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?