mingw-users

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Oscar B. <osc...@gm...>]

On 23 May 2013 17:22, Earnie Boyd <ea...@us...> wrote:
> On Thu, May 23, 2013 at 11:46 AM, Oscar Benjamin wrote:
>>
>> So I thought that I could do something like:
>>
>>   if dumpmachine == "mingw32":
>>     don't use -mno-cygwin
>>
>> or perhaps
>>
>>   if dumpmachine ends with 'cygwin':
>>     use -mno-cygwin
>>
>> Can anyone confirm/deny (or improve) the reliability of either of the
>> above methods to distinguish between cygwin and mingw gcc?
>
> The dumpmachine idea isn't a bad one but Cygwin itself no longer uses
> -mno-cygwin.  If you want a native build using Cygwin tools you'll
> need to use a cross compiler and specify a --host=i686-pc-mingw32 or
> whatever appropriate triplet.

Thanks Earnie. To be clear, distutils does not currently support
Cygwin's cross-compilers. Support for that may be added but this is
not what I am currently trying to achieve.

The final problem I want to solve is that currently a user who
(incorrectly) attempts to use distutils no-cygwin mode with Cygwin's
gcc 4.x sees the following error message:

$ /q/tools/cygwin/bin/gcc-4 -mno-cygwin
gcc-4: The -mno-cygwin flag has been removed; use a mingw-targeted
cross-compiler.

Having distutils -mno-cygwin conditional on gcc major version fixes
the problem for mingw users without, I believe, causing any problems
for any functioning no-cygwin setup. However if someone tried
(incorrectly) to use Cygwin's gcc-4 in no-cygwin mode then they would
no longer see the above error message; instead they would either get
obscure compilation errors or an incorrectly linked executable. I
would like to preserve the vaguely meaningful error message for those
users.

So my actual full suggestion is for distutils to do:

  if gcc_version < 4 or is_cygwingcc():
    use -mno-cygwin
  else:
    don't use -mno-cygwin

The idea is that the version check fixes it for mingw users without
breaking anything for no-cygwin users. The is_cygwingcc() function
only needs to be semi-reliable as it is only there to try and expose
an error message in an already broken setup. Some false negatives are
okay if necessary but false positives are not because it could break
builds for mingw users.

So I thought that is_cygwingcc() can just do:

  if dumpmachine ends with 'cygwin':
    return true
  else:
    return false

On the other hand if I have a totally reliable is_cygwingcc() function
(for all gcc versions and systems) then it can just be as simple as:

  if is_cygwingcc():
    use -mno-cygwin


Thanks again,
Oscar

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Roumen P. <bug...@ro...>]

Hi Oscar,

Oscar Benjamin wrote:
> On 21 May 2013 14:45, Oscar Benjamin <osc...@gm...> wrote:
>> My proposal is to remove '-mno-cygwin' from distutils in Python 3.4
>> and to only use it for gcc 3.x in Python 2.7, 3.2 and 3.3. If anyone
>> sees a problem with that approach I would be very grateful if you
>> could let me know.

Did you review my patch 
0001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patch 
<http://bugs.python.org/file29032/0001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patch> 

posted to python issue issue12641 ?

> Hi all, and sorry to both you again but I have one more question.
>
> I think I can get the above changes into distutils but there is one
> last snag [1]. I can address it if I have a reliable way of querying
> whether or not a given gcc is from cygwin or from mingw. I have found
> a possible way to do this this by testing the output of 'gcc
> -dumpmachine':
>
> $ /q/tools/cygwin/bin/gcc-4.exe -dumpmachine
> i686-pc-cygwin
>
> $ /q/tools/cygwin/bin/gcc-3.exe -dumpmachine
> i686-pc-cygwin
>
> $ /q/tools/MinGW/bin/gcc.exe -dumpmachine
> mingw32
>
> So I thought that I could do something like:
>
>    if dumpmachine == "mingw32":
>      don't use -mno-cygwin
>
> or perhaps
>
>    if dumpmachine ends with 'cygwin':
>      use -mno-cygwin
No . Above is not enough to detect whether -mno-cygwin is supported or not.

> Can anyone confirm/deny (or improve) the reliability of either of the
> above methods to distinguish between cygwin and mingw gcc?
>
>
> [1] http://bugs.python.org/issue12641#msg189770
>
>
> Thanks,
> Oscar

Roumen

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Keith M. <kei...@us...>]

On 23/05/13 17:51, Oscar Benjamin wrote:
> So I thought that is_cygwingcc() can just do:
>
>    if dumpmachine ends with 'cygwin':
>      return true

I would have thought that config.guess is the canonically appropriate 
test here:

   case `config.guess` in
     *cygwin*) # do processing appropriate to cygwin tool-chain ;;
     *) # whatever is appropriate for non-cygwin ;;
   esac

-- 
Regards,
Keith.

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Oscar B. <osc...@gm...>]

On May 23, 2013 8:24 PM, "Keith Marshall" <
kei...@us...> wrote:
>
> On 23/05/13 17:51, Oscar Benjamin wrote:
> > So I thought that is_cygwingcc() can just do:
> >
> >    if dumpmachine ends with 'cygwin':
> >      return true
>
> I would have thought that config.guess is the canonically appropriate
> test here:

Thanks, that does seem appropriate. If distutils were being redesigned it
might be better to do that.

However I don't think that distutils has ever previously assumed that
config.guess exists on the user's system so I don't think I can make that
change in a bugfix release. I doubt that it could go into a new release
either as distutils is "frozen" in general.

Thanks,
Oscar

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Keith M. <kei...@us...>]

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.

-- 
Regards,
Keith.

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Keith M. <kei...@us...>]

On 23/05/13 20:38, Keith Marshall wrote:
> test gcc -mno-cygwin -c -xc /dev/null -o /dev/null

Correction: that doesn't mean to use the test command, (as it implies), 
but to evaluate the exit code from the gcc command; e.g.

   gcc -mno-cygwin -c -xc /dev/null -o /dev/null 2>&1 > /dev/null && {
     # do stuff appropriate when -mno-cygwin is supported
   } || {
     # handle case where it isn't
   }

-- 
Regards,
Keith.

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Oscar B. <osc...@gm...>]

On May 23, 2013 7:19 PM, "Roumen Petrov" <bug...@ro...> wrote:
> Oscar Benjamin wrote:
> > On 21 May 2013 14:45, Oscar Benjamin <osc...@gm...> wrote:
>
> Did you review my patch
> 0001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patch
> <
http://bugs.python.org/file29032/0001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patch
>
>
> posted to python issue issue12641 ?

Hi Roumen, I have reviewed your patch as requested by Martin and as I
already said on the issue tracker I would not accept it (not that it's
actually up to me). Please keep that kind of discussion on the tracker
rather than here.

> >    if dumpmachine ends with 'cygwin':
> >      use -mno-cygwin
> No . Above is not enough to detect whether -mno-cygwin is supported or
not.

I'm not trying to test whether -mno-cygwin is accepted/supported. I'm
trying to test if *not* passing -mno-cygwin will result in a binary that
depends on cygwin.dll. If it will (because it's a Cygwin gcc) I will always
pass -mno-cygwin so that gcc can either build or show the appropriate error
message.

Oscar

Re: [Mingw-users] Fixing mingw support in Python's distutils

[Earnie B. <ea...@us...>]

On Fri, May 24, 2013 at 12:34 PM, Oscar Benjamin wrote:
> I'm not trying to test whether -mno-cygwin is accepted/supported. I'm trying
> to test if *not* passing -mno-cygwin will result in a binary that depends on
> cygwin.dll. If it will (because it's a Cygwin gcc) I will always pass
> -mno-cygwin so that gcc can either build or show the appropriate error
> message.

I don't think you should trust the results of -mno-cygwin, my guess is
eventually it will be dropped even in giving the deprecated warning.
I better method will be to test for the __CYGWIN__ predefined macro in
GCC.

is_mingw=`gcc -E -dM nul.c 2>&1 | grep -q __MINGW32__; echo $?`

That should be enough.  The value of is_mingw will be 0 if it is or 1
if not or there were some other error.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-users] Fixing mingw support in Python's distutils

[niXman <i.n...@gm...>]

Hi,

You can build Python yourself using scripts[1] provided by
MinGW-builds[2] project.
Currently supports the following versions of Python: 2.7.3, 2.7.4, 2.7.5, 3.3.0.

Example:
$>./build x32 --python-only=2.7.3
or:
$>./build x64 --python-only=2.7.3


[1] https://github.com/niXman/mingw-builds
[2] http://sourceforge.net/projects/mingwbuilds/

2013/5/20 Oscar Benjamin <osc...@gm...>:
> Hi all,
>
> I haven't posted to this list before and I'm not sure if it's the
> right place to ask this question. If not then please let me know. I'm
> looking for some help in order to resolve a long-standing issue in
> using mingw with Python.
>
> Building extension modules for Python with recent versions of mingw
> has been broken for some time now. I first encountered the problem
> about two years ago and found this SO question
> http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o
> Shortly after that an issue was opened on the Python tracker:
> http://bugs.python.org/issue12641
> The issue has languished on the tracker for two years since then. As
> someone who builds Python extension modules with mingw I have been
> manually patching distutils in my own Python installations for some
> time now. While this is acceptable for me I'd really like to get this
> fixed so that mingw and Python can work together out of the box.
>
> The issue is (as I understand it) caused by the fact that at some
> point a mingw release removed the deprecated '-mno-cygwin' command
> line option. I believe the option was a relic from when mingw forked
> from cygwin's gcc and that it had at some point been turned into a
> deprecated no-op before at some other point being removed entirely.
> With mingw releases since then it has been necessary to patch
> distutils removing the option in order to build Python extension
> modules with mingw. That much has been understood since two years ago.
> However the patch to simply remove the option has not been accepted. I
> think this is because the core Python devs are unsure who is using
> mingw with Python, what versions of mingw they are using and what
> exactly they are doing with them. This makes it difficult to establish
> whether or not the change could break anyone's current workflow.
> (distutils in particular is a delicate area in Python since it is used
> entirely for installation of third party packages of which there are
> many.)
>
> A number of possibilities have been considered (see the issue link
> above) but a new one has occurred to me. Official Python releases for
> Windows are compiled with MSVC. Currently maintained CPython versions
> (2.6+) are compiled with MSVC 2008 or 2010 and link to msvcr90.dll.
> This places a constraint on which versions of mingw can be used to
> compile extension modules (I remember needing to update my mingw
> because of this). This constraint precludes older versions of mingw
> and the '-mno-cygwin' constraint precludes newer versions. If support
> for linking against msvcr90.dll was added after the '-mno-cygwin'
> option was removed (or after it was made a no-op) then it can be
> proven that anyone using mingw with official CPython binaries is not
> depending on this option. I think that this would help to make the
> case for reviving the issue and getting the patch in.
>
> So my question is: Does anyone know if there ever were any versions of
> mingw that accepted the '-mno-cygwin' option and were also capable of
> linking against msvcr90.dll?
>
> Or even better, can anyone say in which releases of mingw the
> following occurred:
> 1) The '-mno-cygwin' option was made a no-op.
> 2) The '-mno-cygwin' option stopped being accepted.
> 3) Support for msvcr90.dll was added.
>
>
> Thanks in advance,
> Oscar
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> 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



--
Regards,
niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingwbuilds/
___________________________________________________
Another online IDE: http://liveworkspace.org/