From: Oscar B. <osc...@gm...> - 2013-05-24 17:27:34
|
On May 23, 2013 8:41 PM, "Keith Marshall" < kei...@us...> wrote: > > On 23/05/13 17:57, Roumen Petrov wrote: > >> if dumpmachine ends with 'cygwin': > >> use -mno-cygwin> > > > > No . Above is not enough to detect whether -mno-cygwin is supported or not. > > No, but... > > test gcc -mno-cygwin -c -xc /dev/null -o /dev/null > > ...is. Combine that with a check for *cygwin* in the output from either > config.guess, (or from gcc -dumpmachine, if you prefer -- it probably is > simpler when you're already using a gcc options check anyway), and you > have all the information you need to trigger an informative diagnostic, > or as a basis from which to develop an effective cross-compiler solution. I'm not trying to determine if gcc will accept -mno-cygwin. The problem is that Cygwin gcc without -mno-cygwin will do the wrong thing (create a binary that depends on cygwin.dll) or display confusing compilation errors. I want it to just give the appropriate 'stop using -mno-cygwin' error message so I intend to continue passing -mno-cygwin if it is a cygwin gcc. I'm also not trying to develop a cross-compiler solution. I should be clear about the cause of this problem. When someone installs Python, distutils is installed with it. Distutils provides code to compile extension packages using the compilers available on the user's system. Users can supply config files or command line options to select the compiler that distutils will use. So when a user supplies --compiler=mingw32 disutils assumes that mingw gcc is on PATH and starts issuing commands to gcc. At some point it was decided that --compiler=mingw32 could be used when cygwin gcc was on PATH. If -mno-cygwin is given by distutils then mingw will ignore it and cygwin gcc will create a non-cygwin binary. This was IMO a design mistake and it has ultimately resulted in the issue I am trying to fix. If the no-cygwin mode had initially been given its own entry point (e.g. --compiler=no-cygwin) then this issue would have been easily fixed two years ago or would never have occurred. If support is added to distutils for cygwin's cross-compilers (unlikely IMO) then we can trivially avoid all of these problems by using a new entry point --compiler=cygwin-cross. However we must continue to support this unfortunate arrangement for --compiler=mingw32 for backwards compatibility (at least in already released Python versions). Thanks for your help, Oscar |
From: Keith M. <kei...@us...> - 2013-05-24 19:59:20
|
On 24/05/13 18:27, Oscar Benjamin wrote: > I'm not trying to determine if gcc will accept -mno-cygwin. You should be. Only if you do so, can you properly take control of the situation, to issue a *meaningful* diagnostic message, in the case when that necessary support is lacking. Half hearted efforts to fix your issue, such as you advocate, pretty much assure the imminent demise of Python's distutils on the cygwin platform. > I'm also not trying to develop a cross-compiler solution. But you are trying to fix an existing cross-compiler solution, which happens to be incorrectly implemented. > At some point it was decided that --compiler=mingw32 could be used ... ... to invoke a *cross-compiler* which was, at one time, arcanely and improperly named; yes, 'gcc -mno-cygwin' *is* a (now defunct) name for a cygwin-hosted mingw32-gcc cross-compiler! It's just that cygwin devs have now realised the error of their ways, have replaced that arcane naming convention, and now use standard naming. Fixing the issue should be as simple as substituting the appropriate mingw32-gcc cross-compiler name for degenerate references to 'gcc -mno-cygwin'. -- Regards, Keith. |
From: Oscar B. <osc...@gm...> - 2013-05-25 11:26:51
|
On 24 May 2013 20:58, Keith Marshall <kei...@us...> wrote: > On 24/05/13 18:27, Oscar Benjamin wrote: >> I'm not trying to determine if gcc will accept -mno-cygwin. > > You should be. Only if you do so, can you properly take control of the > situation, to issue a *meaningful* diagnostic message, in the case when > that necessary support is lacking. Half hearted efforts to fix your > issue, such as you advocate, pretty much assure the imminent demise of > Python's distutils on the cygwin platform. This not about distutils on the Cygwin platform. Distutils has a separate --compiler=cygwin that is used for building extension modules for a Cygwin Python. In this case both Python and the extension module are built by Cygwin's gcc and both link against cygwin.dll. When someone builds extensions using a Cygwin Python this is what will happen by default. This issue is about someone who has a non-Cygwin Python built with MSVC. The only officially supported compiler for this configuration is the same version of MSVC that was used to build Python. However, you can supply --compiler=mingw32 to use MinGW and if your MinGW is new enough (and you patch distutils to remove -mno-cygwin) it will work. Also, the demise of distutils on *all platforms* is assured; distutils is broken by design. The long term fix is simply to stop using distutils. Progress is being made on this front, most notably in the form of the wheel PEPs. PEP 427 http://www.python.org/dev/peps/pep-0427/ gives Python a formally specified, officially endorsed binary installation format that removes the need for end users to have a build system altogether. This means that in the future developers will be able to build using whatever build system they like e.g. waf, bento, etc instead of distutils and end users will only need pip or some other installation tool to download and extract the binaries. However this is not ready yet and will not be for some time as it requires the authors of the many thousands of packages on PyPI to change the way that they distribute their code. The brokenness of distutils has resulted in heavy monkey-patching; I think that there exists many times more code to monkey-patch distutils than code in distutils itself. This monkey-patching has thwarted previous attempts to overhaul distutils with the result that it is now officially considered "frozen". Only changes that are absolutely necessary to maintain existing functionality will be considered. >> At some point it was decided that --compiler=mingw32 could be used ... > > ... to invoke a *cross-compiler* which was, at one time, arcanely and > improperly named; yes, 'gcc -mno-cygwin' *is* a (now defunct) name for a > cygwin-hosted mingw32-gcc cross-compiler! It's just that cygwin devs > have now realised the error of their ways, have replaced that arcane > naming convention, and now use standard naming. Fixing the issue should > be as simple as substituting the appropriate mingw32-gcc cross-compiler > name for degenerate references to 'gcc -mno-cygwin'. I agree but the best way to determine whether or not to do that should be to require the user to specify --compiler=cygwin-cross rather than try to second guess their setup. At the moment we have code paths that are used for both mingw gcc and Cygwin gcc without a proper way to distinguish which is being used. This has resulted in the issue that I am trying to fix and is the obstacle to a fix since it is now necessary to do different things in the two cases. Oscar |
From: Renato S. <br....@gm...> - 2013-05-25 04:57:04
|
2013/5/24 Oscar Benjamin <osc...@gm...> > I'm not trying to determine if gcc will accept -mno-cygwin. The problem is > that Cygwin gcc without -mno-cygwin will do the wrong thing (create a > binary that depends on cygwin.dll) or display confusing compilation errors. > I want it to just give the appropriate 'stop using -mno-cygwin' error > message so I intend to continue passing -mno-cygwin if it is a cygwin gcc. > > I'm also not trying to develop a cross-compiler solution. I should be > clear about the cause of this problem. When someone installs Python, > distutils is installed with it. Distutils provides code to compile > extension packages using the compilers available on the user's system. > Users can supply config files or command line options to select the > compiler that distutils will use. So when a user supplies > --compiler=mingw32 disutils assumes that mingw gcc is on PATH and starts > issuing commands to gcc. > > At some point it was decided that > --compiler=mingw32 could be used when cygwin gcc was on PATH. If > -mno-cygwin is given by distutils then mingw will ignore it and cygwin gcc > will create a non-cygwin binary. This was IMO a design mistake and it has > ultimately resulted in the issue I am trying to fix. If the no-cygwin mode > had initially been given its own entry point (e.g. --compiler=no-cygwin) > then this issue would have been easily fixed two years ago or would never > have occurred. > > If support is added to distutils for cygwin's cross-compilers (unlikely > IMO) then we can trivially avoid all of these problems by using a new entry > point --compiler=cygwin-cross. However we must continue to support this > unfortunate arrangement for --compiler=mingw32 for backwards compatibility > (at least in already released Python versions). > If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC version check would not work? That is, when --compiler=mingw32 and gcc.version < 4.6 (assuming 4.6 is when it was removed), then add -mno-cygwin to avoid the cygwin dependency. Anyway, any reason to be so open about compiler versions? Pidgin, for example, requires *MinGW* GCC, and more specifically, *version 4.4* (at the moment). They have instructions on how to set it up, so I for example have both gcc 4.7 from MinGW and 4.4 from Pidgin build box living in peace together. |
From: Roumen P. <bug...@ro...> - 2013-05-25 08:51:21
|
Renato Silva wrote: > [SNIP] > If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC > version check would not work? That is, when --compiler=mingw32 and > gcc.version < 4.6 (assuming 4.6 is when it was removed), then add > -mno-cygwin to avoid the cygwin dependency. I think that flag was removed in 4.5 . [SNIP] Roumen |
From: Keith M. <kei...@us...> - 2013-05-25 06:23:37
|
On 25/05/13 05:56, Renato Silva wrote: > If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC > version check would not work? Checking for specific versions of *any* tool is *always* a poor choice; it is a fragile mechanism, when what is really important is whether a specific *feature* is supported, or not. The robust choice is *always* to check for feature support, directly. It is *trivially* easy to check: 1) If the desired host to build for is mingw32. 2) If the current platform compiler builds for cygwin. 3) Given (1) and (2), if 'gcc -mno-cygwin' is a valid method of invoking a mingw32-gcc cross-compiler, or if it should be invoked as 'i686-pc-mingw32-gcc' (or whatever the appropriate name which has been chosen for the cross-compiler may be). Checking each of these features is certainly no more difficult than checking for any specific minimum version of GCC, (which even then may *not* support -mno-cygwin anyway, even if it is <4.6 or whatever). I really don't understand why this non-issue needs so much debate; in pseudo-code: if desired host is mingw32 if default compiler builds for cygwin host if gcc -mno-cygwin works invoke cross-compiler as gcc -mno-cygwin else invoke mingw32 cross-compiler by its canonical name or issue an *appropriate* diagnostic message else invoke regular mingw32 host compiler (and do remember that the regular mingw32 host compiler does not need, never has needed, and may not support -mno-cygwin, so please don't specify it). -- Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2013-05-25 08:34:55
|
Oscar Benjamin wrote: [SNIP] > I'm also not trying to develop a cross-compiler solution. I should be clear > about the cause of this problem. When someone installs Python, distutils is > installed with it. Distutils provides code to compile extension packages > using the compilers available on the user's system. Users can supply config > files or command line options to select the compiler that distutils will > use. So when a user supplies --compiler=mingw32 disutils assumes that mingw > gcc is on PATH and starts issuing commands to gcc. And in current cygwin environment name of compiler for windows is 1) gcc-3.exe -mno-cygwin 2) i686-w64-mingw32-gcc.exe > At some point it was decided that --compiler=mingw32 could be used when > cygwin gcc was on PATH. If -mno-cygwin is given by distutils then mingw > will ignore it and cygwin gcc will create a non-cygwin binary. This was IMO > a design mistake and it has ultimately resulted in the issue I am trying to > fix. And what is wrong with my set of patches ? Did you test them ? Why you think that issue is not resolved yet with proposed set of updates ? Did you build sample python extension in various environments including cygwin ? [SNIP] > If support is added to distutils for cygwin's cross-compilers (unlikely > IMO) then we can trivially avoid all of these problems by using a new entry > point --compiler=cygwin-cross. Please stop to add complexity to python build process. > However we must continue to support this > unfortunate arrangement for --compiler=mingw32 for backwards compatibility > (at least in already released Python versions). Everything is resolved with my set of patches , including past , current and future mingw* compilers in native or posix environment. As posix include cygwin and unix environments. > Thanks for your help, > Oscar > Regards, Roumen |
From: Oscar B. <osc...@gm...> - 2013-05-25 11:36:23
|
On 25 May 2013 05:56, Renato Silva <br....@gm...> wrote: > If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC > version check would not work? That is, when --compiler=mingw32 and > gcc.version < 4.6 (assuming 4.6 is when it was removed), then add > -mno-cygwin to avoid the cygwin dependency. Because then if someone uses Cygwin gcc >= 4.6 with --compiler=mingw32 they might get a broken binary that depends on cygwin.dll (Actually when I tried this I got strange compilation errors coming out of the Python header files). I want to ensure that someone uses --compiler=mingw32 with a version of Cygwin gcc that does not support no-cygwin mode sees an error message that clearly shows they have the wrong compiler. > Anyway, any reason to be so open about compiler versions? Pidgin, for > example, requires *MinGW* GCC, and more specifically, *version 4.4* (at the > moment). They have instructions on how to set it up, so I for example have > both gcc 4.7 from MinGW and 4.4 from Pidgin build box living in peace > together. Any particular package may depend on a particular version of MinGW gcc. It is not the job of distutils to decide which versions are generally acceptable. Although in practise the need to link against the appropriate msvcrxx.dll means that you need a sufficiently new version of MinGW for any given Python version. Oscar |
From: Oscar B. <osc...@gm...> - 2013-05-25 12:34:14
|
On 25 May 2013 07:23, Keith Marshall <kei...@us...> wrote: > On 25/05/13 05:56, Renato Silva wrote: >> If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC >> version check would not work? > > Checking for specific versions of *any* tool is *always* a poor choice; I agree but... > it is a fragile mechanism, when what is really important is whether a > specific *feature* is supported, or not. The robust choice is *always* > to check for feature support, directly. Actually I think the robust choice is to have the user specify the compiler they want to use. > It is *trivially* easy to check: > > 1) If the desired host to build for is mingw32. > 2) If the current platform compiler builds for cygwin. > 3) Given (1) and (2), if 'gcc -mno-cygwin' is a valid method of > invoking a mingw32-gcc cross-compiler, or if it should be invoked > as 'i686-pc-mingw32-gcc' (or whatever the appropriate name which > has been chosen for the cross-compiler may be). > > Checking each of these features is certainly no more difficult than > checking for any specific minimum version of GCC, (which even then may > *not* support -mno-cygwin anyway, even if it is <4.6 or whatever). I agree. I proposed to check the version simply because distutils already does this and I'm trying to keep any patch as minimal as possible to maximise the chance of acceptance (distutils is frozen). You can see the code I'm trying to fix here: http://hg.python.org/cpython/file/0bf4a6b56eb5/Lib/distutils/cygwinccompiler.py#l274 > I really don't understand why this non-issue needs so much debate; Neither do I :) I must admit I'm a little frustrated by how drawn out this has become but I'd just like to take this moment to thank you, Earnie, Paul and everyone else in this thread for your help. It remains to be seen if I can get this fixed but I certainly wouldn't have been able to do it without your help. > in pseudo-code: > > if desired host is mingw32 > if default compiler builds for cygwin host > if gcc -mno-cygwin works > invoke cross-compiler as gcc -mno-cygwin > else > invoke mingw32 cross-compiler by its canonical name > or issue an *appropriate* diagnostic message > else > invoke regular mingw32 host compiler Okay, so in distutils parlance 1) "Desired host" would be what the user gives for --compiler. 2) "Default compiler builds for cygwin host" means invoking gcc and e.g. checking for __CYGWIN__. 3) "gcc -mno-cygwin works" means again invoking gcc with a test compilation file. That looks good but the problem is that adding a new feature (supporting Cygwin's new cross-compilers) cannot happen in a bugfix release. It could happen for Python 3.4 but not for 2.7, 3.2 or 3.3. It could be argued that not using the appropriate name for Cygwin's new cross-compilers is a bug but I think that this will make it harder to get any patch accepted and I really just want to fix building with mingw. I am yet to find any evidence of any *actual users* using Cygwin gcc with --compiler=mingw32. However since it is a documented [1] feature and it does work with gcc 3.x (I've tested this) we have to be very careful to avoid breaking any currently functional setup. But adding support for Cygwin's new cross-compilers should happen in a separate issue on the Python tracker and should be pushed by people who actually intend to use that setup (if they exist). And IMO support for the new Cygwin cross-compilers should use a new --compiler=cygwin-cross entry point so that distutils doesn't have to guess what the user is trying to do. So my version of the above would be: if --compiler is mingw32 if gcc is cygwin (invoke gcc somehow) use gcc -mno-cygwin else use gcc Then someone trying to use Cygwin's gcc 4.x sees an error message that tells them to use a different compiler. > (and do remember that the regular mingw32 host compiler does not need, > never has needed, and may not support -mno-cygwin, so please don't > specify it). I know and I'm sure that the pseudo code I posted previously looks wrong to you as it would sometimes pass -mno-cygwin to MinGW but I was trying to ensure that changes occurred in as few situations as possible while still fixing the error that prevents build with recent mingw. I'm satisfied that this is unnecessary now. [1] http://docs.python.org/2/install/index.html#gnu-c-cygwin-mingw Oscar |
From: Oscar B. <osc...@gm...> - 2013-05-25 12:41:19
|
On 25 May 2013 09:34, Roumen Petrov <bug...@ro...> wrote: > And what is wrong with my set of patches ? Did you test them ? > Why you think that issue is not resolved yet with proposed set of updates ? Please ask this question on the tracker not here. Your patches change too many things; distutils is frozen and will not be overhauled. If you want a patch to be accepted you should make a minimal patch that fixes a specific issue. Also IMO the cross-compilers should use a different --compiler entry point. This design mistake (using --compiler=mingw32 with Cygwin's gcc) is the root cause of issue 12641 and is the reason that it has remained unfixed for 2 years. Your patches IIUC propose to extend this poor design decision by allowing --compiler=mingw32 to be also used for the new Cygwin cross-compilers. Oscar |
From: Roumen P. <bug...@ro...> - 2013-05-25 14:25:52
|
Oscar Benjamin wrote: > On 25 May 2013 09:34, Roumen Petrov <bug...@ro...> wrote: >> And what is wrong with my set of patches ? Did you test them ? >> Why you think that issue is not resolved yet with proposed set of updates ? > Please ask this question on the tracker not here. Your patches change > too many things; distutils is frozen and will not be overhauled. Yet another person why try to use word "frozen" and to reject support for gcc windows compilers in python. "distutils is frozen" is related to another issue and I cannot understand how a set of patches that keep API compatibility an be categorized as breakage. > If > you want a patch to be accepted you should make a minimal patch that > fixes a specific issue. :) Please setup various build environment and try create a simple python extension module written in "C". > Also IMO the cross-compilers should use a different --compiler entry > point. This design mistake (using --compiler=mingw32 with Cygwin's > gcc) is the root cause of issue 12641 and is the reason that it has > remained unfixed for 2 years. Your patches IIUC propose to extend this > poor design decision by allowing --compiler=mingw32 to be also used > for the new Cygwin cross-compilers. My patch restore support to level as it was before. Please note that gcc with -mno-cygwin is cross-compiler !!!! Roumen |
From: Keith M. <kei...@us...> - 2013-05-25 14:05:59
|
On 25/05/13 13:33, Oscar Benjamin wrote: > That looks good but the problem is that adding a new feature > (supporting Cygwin's new cross-compilers) cannot happen in a bugfix > release. Why not? You're *not* adding a new feature; you're just proposing to fix an existing one, which is broken. > It could be argued that not using the appropriate name for Cygwin's > new cross-compilers is a bug but I think that this will make it harder > to get any patch accepted and I really just want to fix building with > mingw. The reality is that you're not really interested in fixing anything at all; the beast is terminally ill, so you may as well just let it die. -- Regards, Keith. |
From: Oscar B. <osc...@gm...> - 2013-05-25 15:20:09
|
On 25 May 2013 15:05, Keith Marshall <kei...@us...> wrote: > On 25/05/13 13:33, Oscar Benjamin wrote: >> That looks good but the problem is that adding a new feature >> (supporting Cygwin's new cross-compilers) cannot happen in a bugfix >> release. > > Why not? You're *not* adding a new feature; you're just proposing to > fix an existing one, which is broken. Because fixing that while still using the same --compiler=mingw32 will require more ugly hacks and make it even more difficult to solve these kinds of problems in future. The real fix would be to have a separate CCompiler class for the Cygwin cross-compilers that is activated by --compiler=cygwin-cross or similar. The fact that Cygwin's new cross-compilers currently don't work provides the opportunity to make that change without backwards compatibility concerns and I believe it could get accepted into Python 3.4. However I don't expect that the same change would be accepted in the other Python versions (It's really not up to me). > The reality is that you're not really interested in fixing anything at > all; I am interested in fixing a long-broken actually used setup that has been complained about repeatedly by many different users including myself. I have never seen anyone complain about the lack of support for Cygwin's new cross compilers and no one has opened an issue on the bug tracker for this. I personally do not object to seeing support added for these but I don't want one issue to prevent the resolution of the other. > the beast is terminally ill, so you may as well just let it die. Quite. Oscar |
From: Roumen P. <bug...@ro...> - 2013-05-25 15:54:34
|
Oscar Benjamin wrote: > On 25 May 2013 15:05, Keith Marshall > <kei...@us...> wrote: >> On 25/05/13 13:33, Oscar Benjamin wrote: >>> That looks good but the problem is that adding a new feature >>> (supporting Cygwin's new cross-compilers) cannot happen in a bugfix >>> release. >> Why not? You're *not* adding a new feature; you're just proposing to >> fix an existing one, which is broken. > Because fixing that while still using the same --compiler=mingw32 will > require more ugly hacks and make it even more difficult to solve these > kinds of problems in future. The real fix would be to have a separate > CCompiler class for the Cygwin cross-compilers that is activated by > --compiler=cygwin-cross or similar. The fact that Cygwin's new > cross-compilers currently don't work provides the opportunity to make > that change without backwards compatibility concerns and I believe it > could get accepted into Python 3.4. However I don't expect that the > same change would be accepted in the other Python versions (It's > really not up to me). Please review in details how distutils work and lets remove "ugly hacks " exiting into current python code. >> The reality is that you're not really interested in fixing anything at >> all; > I am interested in fixing a long-broken actually used setup that has > been complained about repeatedly by many different users including > myself. I have never seen anyone complain about the lack of support > for Cygwin's new cross compilers and no one has opened an issue on the > bug tracker for this. I personally do not object to seeing support > added for these but I don't want one issue to prevent the resolution > of the other. This is just because python refuse to fix issues related to cygwin and mingw. Note that exist issue open before 10(!) years. It seems to that leaving mingw related issues unfixed is intentionall. Roumen |
From: Renato S. <br....@gm...> - 2013-05-26 03:35:10
|
2013/5/25 Oscar Benjamin <osc...@gm...> > On 25 May 2013 05:56, Renato Silva <br....@gm...> wrote: > > If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC > > version check would not work? That is, when > --compiler=mingw32 and > > gcc.version < 4.6 (assuming 4.6 is when it was removed), then add > > -mno-cygwin to avoid the cygwin dependency. > > Because then if someone uses Cygwin gcc >= 4.6 with --compiler=mingw32 > they might get a broken binary that depends on cygwin.dll (Actually > when I tried this I got strange compilation errors coming out of the > Python header files). I want to ensure that someone uses > --compiler=mingw32 with a version of Cygwin gcc that does not support > no-cygwin mode sees an error message that clearly shows they have the > wrong compiler. > Then why not just stop build? Why not say, we do not support newer GCC versions in Cygwin (they don't currently work anyway, due to unrecognizing that flag). Something like this pseudocode: if --compiler=mingw32 if gcc.from.mingw just compile else # from cygwin if gcc.major.version < 4 # like you said in the Python issue current code, continue passing -mno-cygwin else abort saying "we do not support GCC from 4.x on under Cygwin" > > Anyway, any reason to be so open about compiler versions? Pidgin, for > > example, requires *MinGW* GCC, and more specifically, *version 4.4* (at > the > > moment). They have instructions on how to set it up, so I for example > have > > both gcc 4.7 from MinGW and 4.4 from Pidgin build box living in peace > > together. > > Any particular package may depend on a particular version of MinGW > gcc. It is not the job of distutils to decide which versions are > generally acceptable. Although in practise the need to link against > the appropriate msvcrxx.dll means that you need a sufficiently new > version of MinGW for any given Python version. > I think the benefits from letting that so open to extension developers do not compensate the effort it requires in problems like this. I'm not saying to drop support for ancient GCC in releases of distutils that are frozen for feature changes, but I would consider this restriction policy for new major releases (preferably moving on and keeping up to date with newest GCC versions, consecutively removing old GCCs from support list on major releases). BTW what you said there in the Python issue confused me. GCC 4.x does not accept -m-no-cygwin in Cygwin, but in MinGW it was removed only in 4.5 or 4.6? But didn't folks here say they didn't touch anything about such flag here in MinGW? Can someone clarify this? Anyone can download GCC 4.4 from MinGW and check that it does accept the flag, and that 4.7 (current release by mingw-get here) does not. I did this myself, but how about you? Have you tried yourself using such flag in Cygwin's GCC 3.x and 4.x to verify that what Cygwin said about 4.x not accepting it has actually come to reality? |
From: Keith M. <kei...@us...> - 2013-05-26 19:36:54
|
On 26/05/13 04:34, Renato Silva wrote: > Then why not just stop build? Why not say, we do not support newer GCC > versions in Cygwin (they don't currently work anyway, due to unrecognizing > that flag). Something like this pseudocode: > > if --compiler=mingw32 > if gcc.from.mingw > just compile > else # from cygwin > if gcc.major.version < 4 # like you said in the Python issue This is absolutely the wrong way to tackle this; in 99.999% of cases, checking for a specific version, or version range, of *any* tool is the worst possible choice you could make. > current code, continue passing -mno-cygwin > else > abort saying "we do not support GCC from 4.x on under Cygwin" >> Any particular package may depend on a particular version of MinGW >> gcc. Why? It may depend on a specific *feature* of gcc, but to deduce the availability of such a feature on the basis of a version check is quite simply STUPID IN THE EXTREME. >> It is not the job of distutils to decide which versions are >> generally acceptable. Quite. It should be checking for feature support, *not* for any particular minimum *version*. >> Although in practise the need to link against >> the appropriate msvcrxx.dll means that you need a sufficiently new >> version of MinGW for any given Python version. Rubbish! If you need anything which isn't MSVCRT.DLL, then your application is non-free, and needs an appropriate version of MSVC. MinGW allows you to build non-free code, but this isn't something we encourage. We may offer you the import libs to facilitate your endeavour, but it's your responsibility, (or your end users'), to furnish the necessary non-free MSVC DLLs. However, the ability to make your application non-free, in this manner, isn't tied to *any* version of MinGW's gcc; it depends solely on the version of mingwrt furnishing the appropriate import libs, (and on your licensing provisions for distribution of, and/or your end users' willingness to obtain and/or deploy those non-free DLLs); you *cannot* predicate this on the basis of *any* gcc version check, (and this is why version checks, in general, are so fundamentally *wrong*). > BTW what you said there in the Python issue confused me. GCC 4.x does not > accept -m-no-cygwin in Cygwin, but in MinGW it was removed only in 4.5 or > 4.6? But didn't folks here say they didn't touch anything about such flag > here in MinGW? Can someone clarify this? Cygwin discontinued infrastructure support, when they moved from GCC-3.x to GCC-4.x; upstream GCC removed option support later. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2013-05-26 19:46:25
|
On 25/05/13 16:54, Roumen Petrov wrote: > This is just because python refuse to fix issues related to cygwin and > mingw. Note that exist issue open before 10(!) years. > > It seems to that leaving mingw related issues unfixed is intentionall. Quite. I'd agree that your patch tries to do too much all at once; it should be broken down into more manageable atomic units. That said, it is obvious that the mindset of the distutils maintainers is focussed on concocting excuses for doing nothing, rather than fixing issues; the project either needs a proactive fork, to get it moving again, or it must die; (it already appears to be in its death throes). -- Regards, Keith. |
From: Oscar B. <osc...@gm...> - 2013-05-27 13:08:30
|
On 26 May 2013 20:46, Keith Marshall <kei...@us...> wrote: > > That said, it > is obvious that the mindset of the distutils maintainers is focussed on > concocting excuses for doing nothing, rather than fixing issues; I think that this is a little unfair; they are in a very difficult position here. I do think it's a shame that free compilers are not officially supported on Windows though. > the > project either needs a proactive fork, to get it moving again, or it > must die; (it already appears to be in its death throes). There were forks and extensions aplenty. The most proactive was setuptools which fixed a lot of other issues (unrelated to building C extensions). Unfortunately distutils was not easily extensible so setuptools ended up turning into a giant monkeypatch around it that then obstructed any ability to fix distutils itself. Then distutils was forked into distutils2/packaging and setuptools was forked into distribute and no one even knows what they should be using any more. Oscar |
From: Oscar B. <osc...@gm...> - 2013-05-27 12:53:52
|
On 26 May 2013 20:36, Keith Marshall <kei...@us...> wrote: > On 26/05/13 04:34, Renato Silva wrote: >> >> if gcc.major.version < 4 # like you said in the Python issue > > This is absolutely the wrong way to tackle this; in 99.999% of cases, > checking for a specific version, or version range, of *any* tool is the > worst possible choice you could make. I understand what you mean and I agree. I proposed a version check in order to make the changes more conservative but I no longer think that it's necessary. >>> Any particular package may depend on a particular version of MinGW >>> gcc. > > Why? It may depend on a specific *feature* of gcc, but to deduce the > availability of such a feature on the basis of a version check is quite > simply STUPID IN THE EXTREME. Agreed. Distutils never refuses to build based on any version check. However a particular package may fail to build if it depends on unavailable compiler features (the error would come from the compiler not distutils). >>> It is not the job of distutils to decide which versions are >>> generally acceptable. > > Quite. It should be checking for feature support, *not* for any > particular minimum *version*. Ideally it doesn't check anything at all; gcc et al. can report errors if they find them. The problem is that removing -mno-cygwin when using the Cygwin cross-compilers doesn't report the appropriate error and may simply create an incorrect binary. >>> Although in practise the need to link against >>> the appropriate msvcrxx.dll means that you need a sufficiently new >>> version of MinGW for any given Python version. > > Rubbish! If you need anything which isn't MSVCRT.DLL, then your > application is non-free, and needs an appropriate version of MSVC. > MinGW allows you to build non-free code, but this isn't something we > encourage. We may offer you the import libs to facilitate your > endeavour, but it's your responsibility, (or your end users'), to > furnish the necessary non-free MSVC DLLs. The python.org installers ship the relevant msvcrXX.dll and place it in the root of the Python installation. It is then used by all extension modules in that Python installation. > However, the ability to make > your application non-free, in this manner, isn't tied to *any* version > of MinGW's gcc; it depends solely on the version of mingwrt furnishing > the appropriate import libs, (and on your licensing provisions for > distribution of, and/or your end users' willingness to obtain and/or > deploy those non-free DLLs); you *cannot* predicate this on the basis of > *any* gcc version check, (and this is why version checks, in general, > are so fundamentally *wrong*). Agreed. Distutils does not do this. It (or the linker?) raises an error if the necessary msvcrXX.dll file cannot be found. I found that the easiest way to get it working again was simply to update MinGW but I didn't realise that it was only the mingwrt component that needed updating. Oscar |
From: Keith M. <kei...@us...> - 2013-05-27 18:11:53
|
On 27/05/13 13:53, Oscar Benjamin wrote: > The python.org installers ship the relevant msvcrXX.dll and place it > in the root of the Python installation. It is then used by all > extension modules in that Python installation. And this makes python itself non-free on the MS-Windows platform; while python.org may have a paid-for licence (from Microsoft) to redistribute those MSVC specific DLLs, the end user acquiring such software from python.org is denied the freedom to redistribute it, unless he/she also has a paid-for licence to do so. This is contrary to the ethic of free software. -- Regards, Keith. |
From: Renato S. <br....@gm...> - 2013-05-28 03:22:03
|
2013/5/27 Oscar Benjamin <osc...@gm...> > The python.org installers ship the relevant msvcrXX.dll and place it > in the root of the Python installation. It is then used by all > extension modules in that Python installation. > I can't find any DLL named like that in my Python installation: $ python.exe --version Python 2.7.3 $ type python.exe python.exe is hashed (/windows/Programs/Desenvolvimento/Python/python.exe) $ type find.exe find.exe is hashed (/bin/find.exe) $ find.exe /windows/Programs/Desenvolvimento/Python -iname '*msvcr*' $ # nothing found |
From: Oscar B. <osc...@gm...> - 2013-05-28 12:38:34
|
On 28 May 2013 04:21, Renato Silva <br....@gm...> wrote: > > 2013/5/27 Oscar Benjamin <osc...@gm...> >> >> The python.org installers ship the relevant msvcrXX.dll and place it >> in the root of the Python installation. It is then used by all >> extension modules in that Python installation. > > I can't find any DLL named like that in my Python installation: These are fresh installs of Python 2.7, 3.2 and 3.3 using the MSI installers from python.org (http://www.python.org/getit/): $ ls /q/tools/Python*/*.dll /q/tools/Python27/msvcr90.dll /q/tools/Python32/msvcr90.dll /q/tools/Python33/msvcr100.dll /q/tools/Python27/python27.dll /q/tools/Python32/python32.dll /q/tools/Python33/python33.dll Oscar |
From: Paul M. <p.f...@gm...> - 2013-05-28 12:45:39
|
If you do an "All users" install, these probably end up in C:\Windows\System32... On 28 May 2013 13:38, Oscar Benjamin <osc...@gm...> wrote: > On 28 May 2013 04:21, Renato Silva <br....@gm...> wrote: > > > > 2013/5/27 Oscar Benjamin <osc...@gm...> > >> > >> The python.org installers ship the relevant msvcrXX.dll and place it > >> in the root of the Python installation. It is then used by all > >> extension modules in that Python installation. > > > > I can't find any DLL named like that in my Python installation: > > These are fresh installs of Python 2.7, 3.2 and 3.3 using the MSI > installers from python.org (http://www.python.org/getit/): > > $ ls /q/tools/Python*/*.dll > /q/tools/Python27/msvcr90.dll > /q/tools/Python32/msvcr90.dll > /q/tools/Python33/msvcr100.dll > /q/tools/Python27/python27.dll > /q/tools/Python32/python32.dll > /q/tools/Python33/python33.dll > > > Oscar > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Renato S. <br....@gm...> - 2013-05-29 03:46:12
|
2013/5/28 Paul Moore <p.f...@gm...> > If you do an "All users" install, these probably end up in > C:\Windows\System32... > It seems the case. Only when installed for current user is that the Microsoft runtime gets placed in root of Python install. In my installation for all users, C:\Windows\system32\python27.dll points to that other big path to MSVCRT in Dependency Walker. If it wasn't for the odd creation/modification dates, I would think the big path is created by Python installer rather than Windows. > > > On 28 May 2013 13:38, Oscar Benjamin <osc...@gm...> wrote: > >> On 28 May 2013 04:21, Renato Silva <br....@gm...> wrote: >> > >> > 2013/5/27 Oscar Benjamin <osc...@gm...> >> >> >> >> The python.org installers ship the relevant msvcrXX.dll and place it >> >> in the root of the Python installation. It is then used by all >> >> extension modules in that Python installation. >> > >> > I can't find any DLL named like that in my Python installation: >> >> These are fresh installs of Python 2.7, 3.2 and 3.3 using the MSI >> installers from python.org (http://www.python.org/getit/): >> >> $ ls /q/tools/Python*/*.dll >> /q/tools/Python27/msvcr90.dll >> /q/tools/Python32/msvcr90.dll >> /q/tools/Python33/msvcr100.dll >> /q/tools/Python27/python27.dll >> /q/tools/Python32/python32.dll >> /q/tools/Python33/python33.dll >> >> >> Oscar >> >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring >> service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! >> http://p.sf.net/sfu/newrelic_d2d_may >> _______________________________________________ >> MinGW-users mailing list >> Min...@li... >> >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for the list >> etiquette may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> Also: mailto:min...@li... >> ?subject=unsubscribe >> > > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: Eli Z. <el...@gn...> - 2013-05-28 15:05:21
|
> From: Renato Silva <br....@gm...> > Date: Tue, 28 May 2013 00:21:12 -0300 > > 2013/5/27 Oscar Benjamin <osc...@gm...> > > > The python.org installers ship the relevant msvcrXX.dll and place it > > in the root of the Python installation. It is then used by all > > extension modules in that Python installation. > > > > I can't find any DLL named like that in my Python installation: > > $ python.exe --version > Python 2.7.3 > > $ type python.exe > python.exe is hashed (/windows/Programs/Desenvolvimento/Python/python.exe) > > $ type find.exe > find.exe is hashed (/bin/find.exe) > > $ find.exe /windows/Programs/Desenvolvimento/Python -iname '*msvcr*' > $ # nothing found Run depends.exe on Python DLL, and you will see where it keeps those libraries. (They could be in the SxS directories somewhere.) |