Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Next: Fascinating interview by Richard Stallman on Russia TV
From: Martin v. Loewis on 7 Jul 2010 15:56 >>> Perhaps (if it isn't intentional) this is a bug of the oversight type, >>> that nobody remembered to update the macro? >> >> Update in what way? > > I was guessing that at one time there was no PyMem_Malloc. And that it > was introduced to fix Windows-specific problems, but inadvertently > without updating the macro. It's just a guess as to reasons why the > macro uses malloc directly. It might indeed be that the function version was introduced specifically for Windows. However, the macro was left intentionally: both for backwards compatibility, and for use inside Python itself. >>> Except for the problems with file descriptors I think a practical >>> interim solution for extensions implemented in C could be to just link >>> the runtime lib statically. [...] > > When I wrote "link the runtime lib statically" that was an alternative > to the usual link-as-DLL. Ok, I lost the thread. When you said "a practical interim solution" you were talking about what problem? I thought the discussion was about the need to link with the same DLL version as Python. > It wouldn't make sense to link the runtime lib statically as an > alternative to linking it statically. However, it would surely make sense to link with a different DLL than the one that Python links with, assuming that would actually work. > As for linking to a different /version/ of the CRT, if you really mean > that, I think that's difficult. It's not necessarily impossible, after > all there's STLPort. But I think that it must at the very least be > rather difficult to do with Microsoft's tools, for otherwise people > would have employed that solution before, and so I wouldn't trust the > result, and wouldn't waste the time trying. It's actually straight-forward (or used to be, until they came up with the SxS madness). It was actually the case that people did so unexpectingly, and it seemed to work fine, except that it crashed when passing FILE*. Then we started explaining that mixing CRTs is risky. Regards, Martin
From: Alf P. Steinbach /Usenet on 7 Jul 2010 16:07
* Martin v. Loewis, on 07.07.2010 21:56: >>>> Perhaps (if it isn't intentional) this is a bug of the oversight type, >>>> that nobody remembered to update the macro? >>> >>> Update in what way? >> >> I was guessing that at one time there was no PyMem_Malloc. And that it >> was introduced to fix Windows-specific problems, but inadvertently >> without updating the macro. It's just a guess as to reasons why the >> macro uses malloc directly. > > It might indeed be that the function version was introduced specifically > for Windows. However, the macro was left intentionally: both for > backwards compatibility, and for use inside Python itself. > >>>> Except for the problems with file descriptors I think a practical >>>> interim solution for extensions implemented in C could be to just link >>>> the runtime lib statically. > [...] >> >> When I wrote "link the runtime lib statically" that was an alternative >> to the usual link-as-DLL. > > Ok, I lost the thread. When you said "a practical interim solution" > you were talking about what problem? I thought the discussion was > about the need to link with the same DLL version as Python. The main problem that the required MSVC redistributables are not necessarily present on the end user's system. >> It wouldn't make sense to link the runtime lib statically as an >> alternative to linking it statically. > > However, it would surely make sense to link with a different DLL than > the one that Python links with, assuming that would actually work. > >> As for linking to a different /version/ of the CRT, if you really mean >> that, I think that's difficult. It's not necessarily impossible, after >> all there's STLPort. But I think that it must at the very least be >> rather difficult to do with Microsoft's tools, for otherwise people >> would have employed that solution before, and so I wouldn't trust the >> result, and wouldn't waste the time trying. > > It's actually straight-forward (or used to be, until they came up with > the SxS madness). It was actually the case that people did so > unexpectingly, and it seemed to work fine, except that it crashed when > passing FILE*. Then we started explaining that mixing CRTs is risky. Oh. Well then. :-) Cheers, - Alf -- blog at <url: http://alfps.wordpress.com> |