Re: [Python-Dev] Status of C compilers for Python on Windows
Victor Stinner wrote: Hi, [SKIP] === MinGW Some people tried to compile Python. See for example: https://bitbucket.org/puqing/python-mingw We even got some patches: http://bugs.python.org/issue3871 (rejected) [SNIP] As all in one patch it was rejected , but you could find splits: 17605 - mingw-meta: build interpeter core 18653 - mingw-meta: build core modules Lot of people post links to possible issues using GCC windows compiler. A lot of them are not real issues for CPython. In addition for those why would like to cross compile C-extensions for MS Windows either from linux of cygwin then could use this set: 18654 - modernize mingwcygwin compiler classes I could step in as maintainer for Cygwin and builds based on GCC using mingw* APIs. Regards, Roumen Petrov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of C compilers for Python on Windows
Paul Moore wrote: On 10 October 2014 17:28, Mark Lawrence breamore...@yahoo.co.uk wrote: There are 55 open issues on the bug tracker with mingw in the title. It's not easy to tell, but on a spot check a fair proportion of them seem to be about distutils/extension builds. And a lot of the rest are related to http://bugs.python.org/issue3871 which is a rejected issue about adding build support for mingw. Rejection is for all in one. It was requested to split in separate patches to be able developers to review them more easy. Paul Roumen ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 port
Matthias Klose wrote: [No, I'm not interested in the port myself] patches for a mingw32 port are floating around on the web and the python bug tracker, although most of them as a set of patches in one issue addressing several things, and which maybe outdated for the trunk. at least for me re-reading a big patch in a new version is more work than having the patches in different issues. So proposing to break down the patches in independent ones, dealing with: - mingw32 support (excluding any cross-build support). tested with a native build with srcdir == builddir. The changes for distutils mingw32 support should be a separate patch. Who could review these? Asked Martin, but didn't get a reply yet. - patches to cross-build for mingw32. - patches to deal with a srcdir != builddir configuration, where the srcdir is read-only (please don't mix with the cross-build support). All work should be done on the tip/trunk. So ok to close issue16526, issue3871, issue3754 and suggest in the reports to start over with more granular changes? I post first part of split of issue3871 . It is related only to build of interpreter core. Second part consist of 23 patches related to build of standard extensions . 3 of them are reported as separate issue by other users. As prerequisite is modernization of cygwincompiler.py - ref issue12641. I will post after 2-3 weeks remaining 20 granular updates. Third part is now with only tree updates related to installation (new). Unlike issue3871 will be supported posix installation scheme as all users refuse to use windows scheme. Matthias Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
Trent Nelson wrote: [SNIP] diff -r 51ce9830d85a configure.ac --- a/configure.ac Sat Oct 13 11:58:23 2012 -0400 +++ b/configure.ac Tue Oct 16 09:12:56 2012 + @@ -9,6 +9,9 @@ AC_INIT(python, PYTHON_VERSION, http://bugs.python.org/) +BUILDDIR=`pwd` ^ http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html [SNIP] However, the 2.69 version of autoconf generates this monster of a configure diff: It is python project rule to keep generated files into repository. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
Brett Cannon wrote: On Sat, Jun 26, 2010 at 16:37, M.-A. Lemburgm...@egenix.com wrote: Brett Cannon wrote: On Wed, Jun 23, 2010 at 14:53, Brett Cannonbr...@python.org wrote: [SKIP] Since no one objected I swapped the order in r82259. In case anyone else uses clang to compile Python, this means that -Wno-unused-value will now work to silence the warning about unused return values that is caused by some macros. Probably using -Wno-empty-body is also good to avoid all the warnings triggered by the UCS4 macros in cjkcodecs. Right now you cannot change order of CFLAGS and OPT I think you need to come up with a different solution and revert the change... OPT has historically been the only variable to use for adjusting the Python C compiler settings. Just found the relevant section in the README. As the name implies this was usually used to adjust the optimizer settings, including raising the optimization level from the default or disabling it. It meant optional to me, not optimization. I hate abbreviations sometimes. With your change CFLAGS will always override OPT and thus any optimization definitions made in OPT will no longer have an effect. That was the point; OPT defines defaults through configure.in and I simply wanted to add to those instead of having OPT completely overwritten by me. Now if you confirm that (see configure.in ) : # Optimization messes up debuggers, so turn it off for # debug builds. OPT=-g -O0 -Wall $STRICT_PROTO is not issue for py3k then left you commit as is (Note that Mark point this). But if optimization messes up debuggers you may revert change. I know that is difficult to reach consensus on compiler/preprocessor flags for python build process. Next is a shot list with issues about this: - Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 : http://bugs.python.org/issue1628484 (committed/rejected) - Python does not honor CFLAGS environment variable : http://bugs.python.org/issue1453 (wont fix) - configure: allow user-provided CFLAGS to override AC_PROG_CC defaults : http://bugs.python.org/issue8211 (fixed) This is still open configure doesn't set up CFLAGS properly ( http://bugs.python.org/issue1104249 ) - must be closed as fixed. Note that CFLAGS defines -O2 on many platforms. So then wouldn't that mean they want that to be the optimization level? Or is the historical reason that default exists is so that some default exists but to expect the application to override as desired? In your particular case, you should try setting OPT to ... -Wno-unused-value ... (ie. replace -Wall with your setting). So what is CFLAGS for then? ``configure -h`` says it's for C compiler flags; that's extremely ambiguous. And it doesn't help that OPT is not mentioned by ``configure -h`` as that is what I have always gone by to know what flags are available for compilation. -Brett If you like to see some flags the could you look into http://bugs.python.org/issue3718 how to define an option to be visible by configure --help. In addition AC_ARG_VAR will allow environment variable to be cached for subsequent run of config.status otherwise you must specify only on configure command line. About all XXflags variables if is good configure script to be simplified to use only CPPFLAGS and CFLAGS to minimize configuration troubles and other build falures. A good sample if configure set preprocessor/compiler flags other then CPPFLAGS/CFLAGS is this issue OSX: duplicate -arch flags in CFLAGS breaks sysconfig ( http://bugs.python.org/issue8607 ) Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what environment variable should contain compiler warning suppression flags?
Brett Cannon wrote: I finally realized why clang has not been silencing its warnings about unused return values: I have -Wno-unused-value set in CFLAGS which comes before OPT (which defines -Wall) as set in PY_CFLAGS in Makefile.pre.in. I could obviously set OPT in my environment, but that would override the default OPT settings Python uses. I could put it in EXTRA_CFLAGS, but the README says that's for stuff that tweak binary compatibility. So basically what I am asking is what environment variable should I use? If CFLAGS is correct then does anyone have any issues if I change the order of things for PY_CFLAGS in the Makefile so that CFLAGS comes after OPT? It is not important to me as flags set to BASECFLAGS, CFLAGS, OPT or EXTRA_CFLAGS will set makefile macros CFLAGS and after distribution python distutil will use them to build extension modules. So all variable are equal for builds. Also after configure without OPT variable set we could check what script select for build platform and to rerun configure with OPT+own_flags set on command line (! ;) ) . Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Christian Tismer wrote:
Hi all,
I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:
I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.
The reason is in objimpl.h:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy; /* force worst-case alignment */
} PyGC_Head;
[SNIP]
Did the crash disappear is you add __attribute__((aligned(8))) after
variable dummy ?
Regards,
Roumen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Antoine Pitrou wrote: Christian Tismer tismer at stackless.com writes: Well, I doubt that a 12 byte long double causes any other alignment but 4. In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). And alignment is ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Antoine Pitrou wrote: Antoine Pitrou solipsis at pitrou.net writes: Roumen Petrov bugtrack at roumenpetrov.info writes: Antoine Pitrou wrote: In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!). And alignment is ? 16 bytes as well. This is probably why, by the way, a PyGC_Head takes only 12 bytes in 32-bit mode, but 32 bytes in 64-bit mode. yes, 10x Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Christian Tismer wrote:
Hi all,
I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:
I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.
The reason is in objimpl.h:
typedef union _gc_head {
struct {
union _gc_head *gc_next;
union _gc_head *gc_prev;
Py_ssize_t gc_refs;
} gc;
long double dummy; /* force worst-case alignment */
} PyGC_Head;
Mingw32 behaves funny here. The size of long double is 12 ! 8-)
No it is correct. GNU C compiler for windows support 80-bit extended
precision.
I happened to use the _PyObject_GC_UNTRACK macro in psyco, instead
of the function, and that caused the errors, because psython
and the extension disagreed on the location of the gc pointers...
Using PyObject_GC_Untrack instead fixed the problem,
but there is a bad feeling left.
Question:
Is that considered a mingw bug?
No as sizeof(long double) = sizeof(double) is MSVC limitation.
Should we change the above union to a safer construct?
Or maybe I just missed something obvious and made a fool out of me?
cheers - chris
Regards,
Roumen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Martin v. Löwis wrote: [SNIP] No. tim_one changed it to be long double in r25454 to support some system that Dave Abrahams uses, so it needs to stay that way :-) However, we can certainly acknowledge that this is a bug in MingW, and special case it. Either introduce a symbolic type gchead_align_t which gets defined to just double on MingW, or put the #ifdef right into the structure. No this is not GCC bug. GCC support hardware extended precision as implement long double and mingw w32api implement long double functions. According to http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx it is MSVC limitation. It might also be useful to assert that sizeof(gchead_align_t) is 8 or 16, and reject 12 as a value. The point is that we need the maximum alignment, and that certainly shouldn't be 12. So look like python bug. Regards, Martin Regards, Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw32 and gc-header weirdness
Christian Tismer wrote: On 7/22/09 4:56 PM, Roumen Petrov wrote: Martin v. Löwis wrote: [SNIP] No. tim_one changed it to be long double in r25454 to support some system that Dave Abrahams uses, so it needs to stay that way :-) However, we can certainly acknowledge that this is a bug in MingW, and special case it. Either introduce a symbolic type gchead_align_t which gets defined to just double on MingW, or put the #ifdef right into the structure. No this is not GCC bug. GCC support hardware extended precision as implement long double and mingw w32api implement long double functions. According to http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx it is MSVC limitation. It might also be useful to assert that sizeof(gchead_align_t) is 8 or 16, and reject 12 as a value. The point is that we need the maximum alignment, and that certainly shouldn't be 12. So look like python bug. The assumption is that the union with long double gives alignment to the largest possible integral type with a power of 2 size, which is then wrong, because of the unexpected size. As is posted for GCC on linux(32-bit) size of structure is 12 = sizeof(struct in union) = sizeof(pointer)+sizeof(pointer)+sizeof(ssize_t). And sizeof(ssize_t) = sizeof(long) = sizeof(pointer) . What do you propose for doing proper alignment, then? May be void* dummy[4] is better for force alignment ? What about alignment on platforms with pointers 32 bit ? I fear this needs to become yet another special case in pyconfig.h cheers - chris Regards, Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
Luke Kenneth Casson Leighton wrote: [SNIP] Yes it is enough to encapsulate memory allocation and file functions into python shared library. The python provide memory allocation functions, but not all modules use them. File functions are hiden by posixmodule and python modules can't use them. except ... posixmodule gets renamed to ntmodule oh, i see what you mean: python modules aren't allowed _direct_ access to msvcrtNN's file functions, they have to go via posixmodule-renamed-to-ntmodule. thinking about this some more... posixmodule.c is linked (by default) into pythonNN.dll, thus making pythonNN.dll totally dependent on a version of msvcrt. This is not problem. If python*.dll hide msvcrt and other modules depend directly from python*.dll I expect issue to be resolved. i.e. python*.dll to be portable runtime interface. decoupling posixmodule.c from pythonNN.dll leaves the possibility to make python independent of msvcrt versioning. it would need to be a custom-compiled .pyd module, due to the early dependency. i'll see if this is possible. Румен ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Roumen Petrov wrote: Cesare Di Mauro wrote: Have you made some benchmarks like pystone? Its seems to me version 2.6.1 is not optimized build so I remove(uninstall) it. I repeat the pystone tests with an optimized GCC(mingw32) build. - python-trunk-GCC(mingw32, local, native, optimized) -- shell=cmd.exe 35453,3; 35700,4; 35747,3; 35615,5; 35632,3; 35661,8; 35547,1 average=35622,5 deviation=98,0 -- shell=bash.exe(msys) 36002,1; 35884,4; 35961,7; 35859,5; 35997,3; 36062,9; 35747,1 average=35930,7 deviation=107,2 - python-2.6-MSVC -- shell=cmd.exe 35891,3; 35827,9; 35791,3; 35901,7; 35876,5; 36081,1; 36149,2 average=35931,3 deviation=132,7 -- shell=bash.exe(msys) 35532,9; 35621,1; 35526,8; 35639,4; 35671,2; 35702,4; 35633,0; average=35618,1 deviation=66,1 I don't have idea why performance of official python 2.6 goes down(see previous results below). It is same PC. Every tested program load own files. The result show unexpected behaviour: - the MSVC build is faster by ~0.9% if it is run under cmd.exe then msys bash; - the GCC build is faster by ~0.9% if it is run under msys bash. Otherwise results lock similar but note that builds use different source base and in this case we may can't compare. The old results: There is result from pystone test test run an old PC (NT 5.1): - 2.6(official build): 42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1 average=42429,4 deviation=311,6 - 2.6.1(official build): 35612,1; 35778,8; 35666,7; 35697,9; 35514,9; 35654,0 average=35654,1 deviation=88,1 - trunk(my mingw based build): 35256,7; 35272,5; 35247,2; 35270,7; 35225,6; 35233,5 average=35251,0 deviation=19,2 There is problem with python performance between 2.6 and 2.6.1 ~ 19% :(. Also the test for GCC-mingw is not with same source base. Roumen Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
Luke Kenneth Casson Leighton wrote: On Fri, Jan 23, 2009 at 10:48 PM, Roumen Petrov [SNIP] but it would certainly mean that there would be both a future-proof path for binary modules from either msvc-compiled _or_ mingw-compiled 2.5, 2.6, 2.7 etc. to work with 2.5, 2.6, 2.7, 2.8 etc. _without_ a recompile. [forwards-future-proof-compatibility _is_ possible, but... it's a bit more... complicated. backwards-compatibility is easy]. what you do is you make sure that the vector-table is always and only extended - added to - never removed from or altered. if one function turns out to be a screw-up (inadequate, not enough parameters), you do NOT change its function parameters, you add an Ex version - or an Ex1 version. [SNIP] but basically, not only is this technique nothing new - it's in use in Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also it's actually _already_ in use in one form in the way that python objects are typecast from PyObject to other types of structs! the difference is that a bit-field would make detection of revisions a bit easier but to be honest you could just as easily make it an int and increase the revision number. This look like simple RCP implemantation. If I remember well SUN-RPC assign number to program, function, version. [SNIP] surely, that should be the _only_ dll which gets _specifically_ linked against msvcr71.dll (or 90, or... whatever) and it would be even _better_ if that then got _named_ msvcr71.pyd, msvcr90.pyd etc. [SNIP] Yes it is enough to encapsulate memory allocation and file functions into python shared library. The python provide memory allocation functions, but not all modules use them. File functions are hiden by posixmodule and python modules can't use them. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?
rdmur...@bitdance.com wrote: On Fri, 23 Jan 2009 at 21:23, Martin v. L�wis wrote: Given that a Unix OS can't know what encoding a filename is in (*), I can't see that one could practically implement a Unix FTP server in any other way. However, an ftp server is different. It might start up with an empty folder, and receive *all* of its files through upload. Then it can certainly know what encoding the file names have on disk. It *could* also support operation on pre-existing files, e.g. by providing a configuration directive telling the encoding of the file names, or by ignoring all file names that are not encoded in UTF-8. I don't see how starting with an empty directory helps. The filename comes from the client, and the FTP server can't know what the actual encoding of that filename is. Exactly, only client can do filename conversion. May be ftplib could be extended to know encoding on filenames on local and remote system based on some user settings. May be ftplib could use UTF-8 or UCS-2/4 to store internally filename but direct conversion is may be faster. It the last case filename is a byte sequence. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
anatoly techtonik wrote: On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov bugtr...@roumenpetrov.info wrote: Against 2.3, rejected due to dependence on SCons. Also appears to have been incomplete, needing more work. No it was complete but use SCons. Most of changes changes in code you will see again in 3871. I would better use SCons for both unix and windows builds. In case of windows for both compilers - mingw and microsoft ones. To port curses extension to windows I need to know what gcc options mean, what are the rules to write Makefiles and how to repeat these rules as well as find options in visual studio interface. Not mentioning various platform-specific defines and warning fixes. Did you select one of existing curses library for windows ? Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: [SNIP] python.exe (say, the official one) loads python25.dll. Then, an import is made of a ming-wine extension, say foo.pyd, which is linked with libpython2.5.dll, which then gets loaded. Voila, you have two interpreters in memory, with different type objects, memory heaps, and so on. ok, there's a solution for that - the gist of the solution is already implemented in things like Apache Runtime and Apache2 (modules), and is an extremely common standard technique implemented in OS kernels. the old school name for it is vector tables. [SNIP] Did you think that this will escape python MSVC from Assembly hell ? Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
[SNIP] No, Python 2.5 is linked with msvcr71.dll. ehn? i don't see that anywhere in any PC/* files - i do see that there's a dependency on .NET SDK 1.1 which uses msvcr71.dll Take a look at PCbuild/pythoncore.vcproj. It says Version=7.10 This is how you know VS 2003 was used to build Python 2.5, which in turn links in msvcr71.dll. Luke, the python MSVC build assume equivalence between MSVC compiler and runtime, i.e. if compiler is version X the runtime is version Y. This is not try for GCC(mingw) build. This compiler is more flexible and allow build against different runtimes. But you know this - I already comment issue870382 in the patch. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Cesare Di Mauro wrote: Have you made some benchmarks like pystone? There is result from pystone test test run an old PC (NT 5.1): - 2.6(official build): 42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1 average=42429,4 deviation=311,6 - 2.6.1(official build): 35612,1; 35778,8; 35666,7; 35697,9; 35514,9; 35654,0 average=35654,1 deviation=88,1 - trunk(my mingw based build): 35256,7; 35272,5; 35247,2; 35270,7; 35225,6; 35233,5 average=35251,0 deviation=19,2 There is problem with python performance between 2.6 and 2.6.1 ~ 19% :(. Also the test for GCC-mingw is not with same source base. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: On Wed, Jan 21, 2009 at 9:13 PM, Martin v. Löwis mar...@v.loewis.de wrote: ok, so - different from what's being generated by ./configure under msys under wine or native win32 - what's being generated (libpython 2 . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin environment. therefore, there's absolutely no doubt that the two are completely different. and on that basis, would i be correct in thinking that you _can't_ go linking or building modules or any python win32 code for one and have a hope in hell of using it on the other, and that you would _have_ to rebuild e.g. numpy for use with a mingw32-msys-built version of python? I can't comment on that, because I don't know what your port does. Does it not produce a .dll containing the majority of Python? no, it contains the minimal necessary amount of python modules, exactly like when python is built using cygwin. actualy, there's a few modules that _have_ to be included. roumen discovered that you have to have these: _functools _functoolsmodule.c# Tools for working with functions and callable objects operator operator.c # operator.add() and similar goodies _locale _localemodule.c # -lintl _struct _struct.c _subprocess ../PC/_subprocess.c _winreg ../PC/_winreg.c Yes and this is issue in native build - setup.py fail to load :(. In cross-build where I use python from build system I could produce those as modules. and i've discovered that when running under wine you have to also have these: _weakref _weakref.c and also when running unde wine with msvcr80, so far, you have to also have these: collections collectionsmodule.c thread threadmodule.c all the rest can be done as .pyd [SNIP] Actually I didn't spend time to find why MSVC build include so many modules as build-ins. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: version. I hope that users will understand that it is disjoint from the python.org version (as they seem to understand fine for the Cygwin build, which already picks up its extension modules also from a disjoint location, which helps to keep the two separate). yes i made the default installation location (--prefix=) c:/python2.5 _not_ c:/python25 but obviously it _has_ been necessary to make the installation of modules into the exact same _style_ of location as the msvc build, because it has obviously also been necessary to use PC/getpathp.c not getpath.c I'm thinking about possibility to avoid compatible paths, i.e. to drop windows specific PC/getpathp.c and to return back to posix getpath.c. The problem is that MSVC based build is not installed in tree compatible to the posix build. Now I think that GCC(mingw) build has to use same tree as other posix builds. Mixing posix build and install (makefile) with paths used by from MSVC build require additional changes either in makefile or in PC/getpathp.c. In the both case change is more the 100 lines and now I prefer mingw to use posix tree. This open another issue. Тhe posix build install in fixed location. I think that with a small change in distutils (no more then 10-20 lines) we may overcome this. so, .pyd modules will get installed in c:/python2.5/lib/site-packages/ and most importantly they'll get _looked_ for in there! for a while, they were being installed in c:/python2.5/lib/python2.5/site-packages which was a bit of a mess - that's the unix style of module locations. getpathp.c looks for Lib/os.py whilst getpath.c looks for os.py there's a whole _stack_ of knock-on effect little things like that. :) The installation is the last issue. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Terry Reedy wrote: Luke Kenneth Casson Leighton wrote: i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue841454 Against 2.3, rejected due to dependence on SCons. Also appears to have been incomplete, needing more work. No it was complete but use SCons. Most of changes changes in code you will see again in 3871. http://bugs.python.org/issue3754 Open by Roumen Petrov, no review, see below. This is again request and the patch is for trunk. It share common idea with 841454:Cross building python for mingw32:Andreas Ames (yxcv):2003-11-13 14:31 1006238:Cross compile patch:Daniel Goertzen (goertzen):2004-08-09 22:05 1597850:Cross compiling patches for MINGW hanwen:2006-11-16 16:57 http://bugs.python.org/issue3871 Open, from same submitter, only (minor) review by you. Does this supercede 3754? No. It share common changes to code with 841454, 1006238, 1412448, 1597850. May be 1597850 and 3871 supercede 1412448. The issue3871 raise questions (and include solution/work around) related to: 2942 - mingw/cygwin do not accept asm file as extension source 2445 - Use The CygwinCCompiler Under Cygwin 1706863 - Failed to build Python 2.5.1 with sqlite3 Also issues related to LDFLAGS: 4010 - configure options don't trickle down to distutils 1628484 - Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [SNIP] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] issue2233: ... extra slash before $(DESTDIR) ... cygwin install fail
Hi All,
May I ask for a vote how issue to be resolved.
The problem is command ... setup.py install ... --root=/$(DESTDIR) if
DESTDIR is specified:
error: could not create '//...': No such host or network path
Currently issue http://bugs.python.org/issue2233 propose three solutions:
1) replace slash before $(DESTDIR) with /./ . Lets call solution
hacky.
2) lets call second one shell script based:
INSTROOT=$(DESTDIR); test -z $$INSTROOT INSTROOT=/; ... setup.py
install ... --root=$$INSTROOT
3) the third shell parameter expansion:
... --root=$${DESTDIR-/}
The question for last one is: So, if a user executes make DESTDIR=
install, then the build will fail. Or, maybe we shouldn't worry about
that corner case.
Which solution is prefered ? What about other solutions ?
Roumen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] report on building of python 2.5.2 under msys under wine on linux.
Luke Kenneth Casson Leighton wrote: [SNIP] i'm going to _try_ to merge in #3871 but it's... the prospect of sitting waiting for configure to take THREE hours to complete, due to /bin/sh.exe instances taking TWO SECONDS _each_ to start up does not really fill me with deep joy. As from version 1.1.8 msys bash could be run in wine. May be wine issue 12046 is not enough to run a born shell in wine. The ash from pw32 projects (not updated in past 6 years :( ) work in wine but the problem is same - it is to slow, even more. [SNIP] it's all a bit odd - it still feels like things are being cross-compiled... but they're not... it's just that setup.py has paths that don't _quite_ match up with the msys environment... You could use CPPFLAGS and LDFLAGS to point other locations. Usually wine drive Z: is mapped to filesystem root and visible as /z in msys. [SNIP] the regression testing is _great_ fun! some of the failures are really quite spectacular, but surprisingly there are less than anticipated. About 5 test fail in emulated environment due bugs in emulator. May be some math tests fail. Python math tests are too strict for msvcrt 7.0/6.0 (default runtime). Simple work around is to use long double functions from mingwex library. Other work-around is to build whole python (including modules) with msvcrt 9.0 but I'm not sure that I will publish soon technical details about this build as DLL hell is replaces by Assembly hell (see python issues related to vista and MSVC build). [SNIP] Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
