| msg19528 - (view) |
Author: Paul Moore (paul.moore) *  |
Date: 2004-01-04 14:55 |
| Python 2.4 is now built with MSVC 7.1, which uses a new MSVC runtime library. Extension DLLs should be built to use the same runtime DLL as Python itself (although it has not been possible to find a real-world example where not doing so causes a problem...) The attached patch adds the appropriate -l flag to the link, based on the MSVC version reported in sys.version. (This has only been tested with a Python built with MSVC 7.1, the version number used for MSVC 7.0 is based on verbal reports only). |
|
|
| msg19529 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-01-04 15:03 |
| Logged In: YES user_id=21627 Could you add some kind of assertion to detect the case that an entirely different compiler version is used? It would be best if it gets the case of using MSVC6 right, and gives up if some other compiler version is detected (I can't determine os.version for the VC6 case right now, but Python 2.3 is built with it). Apart from that, the patch looks good. |
|
|
| msg19530 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2004-01-04 23:01 |
| Logged In: YES user_id=113328 What about Python built with mingw? I don't think that's possible right now, but I'd expect people to work on it. And I've no idea what sys.version for that would be. The only real cases are likely to be MSVC 7.1 (Python 2.4, binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand- built Python versions. The patch does the right thing for all the binary distributions, which are the ones where the user can't be assumed to know how to hack things to make them work. For hand-built versions, the user can do "python setup.py build_ext --compiler=mingw32 -l msvcr71" (or whatever) to manually specify the runtime to use. Leaving the default as msvcrt (the CRT that comes with the OS, and is default for mingw) seems right - and better than aborting (particularly as I'm not sure how to check whether there's an -l option for the CRT specified by the user). The best I could do is effectively to force build_ext to fail unless Python was built with MSVC, which seems unhelpful... |
|
|
| msg19531 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-01-05 21:30 |
| Logged In: YES user_id=21627 I'm primarily concerned about future (unreleased-as-of-today) MSC versions; they likely have version numbers like "1400"; linking msvcr71 to binaries built with that compiler is likely wrong. Not adding anything for gcc-built python versions is fine. |
|
|
| msg19532 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2004-07-09 11:17 |
| Logged In: YES user_id=113328 This is still an issue with 2.4a1. I'm not sure what the autodetection buys given that currently it's not possible to build extensions with 2.4a1 using mingw which are compatible with the stock python.org binary. Can I suggest that this patch be applied, and issues around autodetection be deferred until there is a demonstrated need? I've uploaded a revised patch for 2.4a1 (tested against the python.org supplied MSI). |
|
|
| msg19533 - (view) |
Author: Tony Meyer (anadelonbrin) |
Date: 2004-07-15 04:40 |
| Logged In: YES user_id=552329 FWIW, this patch works for me, and I'd definitely like to see it in 2.4a2. If the MSVC version isn't 1300 or 1310 (the theoretical 1400, for example), then it doesn't do anything different to what 2.4a1 does, so it's hard to see why that would be a problem (and with the patch applied, there's a clear fix, just adding in the appropriate elif and link - it's not like new versions come along all the time). |
|
|
| msg19534 - (view) |
Author: Thomas Heller (theller) * |
Date: 2004-07-16 11:19 |
| Logged In: YES user_id=11105 In principle, it would be possible to examine the import table of pythonxy.dll, to find out to which msvcrXX.dll it is linked to. |
|
|
| msg19535 - (view) |
Author: Paul Moore (paul.moore) * |
Date: 2004-07-29 20:19 |
| Logged In: YES user_id=113328 Can someone suggest what I need to do to get this patch, or something similar, accepted? As things stand, the official Python 2.4 build *does not support* building compatible extensions with mingw, where 2.3 did. I have no means of extending this patch to work with user-built versions of Python - I don't currently have any way of building Python for myself, to test any such change. I don't object to someone making such an extension, but I have seen no-one step forward. I'm getting a little frustrated here. The arguments against applying the patch seem largely theoretical (and outside my expertise). I'd like to invoke "practicality beats purity" here... |
|
|
| msg19536 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-08-03 12:42 |
| Logged In: YES user_id=21627 Thanks for the patch. Applied as cygwinccompiler.py 1.27. |
|
|