Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Keith Marshall <keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f <at> public.gmane.org>
Subject: Re: Fixing mingw support in Python's distutils
Newsgroups: gmane.comp.gnu.mingw.user
Date: Monday 20th May 2013 12:30:43 UTC (over 4 years ago)
On 20 May 2013 12:35, Oscar Benjamin wrote:

> On 20 May 2013 09:50, Keith Marshall wrote:
> > On 19 May 2013 23:37, Oscar Benjamin wrote:
> >>
> >>
> >> Or even better, can anyone say in which releases of mingw the
> >> following occurred:
> >> 1) The '-mno-cygwin' option was made a no-op.
> >
> > MinGW has *never*, AFAIK, *required* -mno-cygwin; it has *always* been
a
> > no-op, (certainly throughout the ten or more years I've been using, and
> > have been associated with MinGW; I have *never* used -mno-cygwin).
>
> Well this is better than I thought. If the '-mno-cygwin' option was
> *never* meaningful for mingw then this is a very simple problem. I
> wonder why this wasn't spotted before. Is there a way for me to
> confirm this by e.g. having a link to the source of an old revision of
> mingw?
>

The sources for *all* previous MinGW releases are available from SF, but
you may need to search the directory trees on one of their mirror sites
to find them; they aren't readily visible on the browseable download
pages.

>> 2) The '-mno-cygwin' option stopped being accepted.
> >
> > You'll have to ask the cygwin folks; they are the architects of the
> > -mno-cygwin madness, and it is only *their* native GCC which has ever
> > implemented it as anything other than a no-op.  I believe that they
> > began the deprecation process during the transition from GCC-3.x to
> > GCC-4.x, but I've no idea how far inertia carried support into 4.x.
>
> If the option was never meaningful for mingw then I think that
> whatever cygwin were doing with it is thankfully irrelevant for this
> problem.


The option was only ever meaningful for *cygwin* native GCC; it was a
nasty kludge they implemented to hide the mechanics of cross-compiling
from their users, while actually invoking mingw32 GCC to cross compile.
Why would native mingw32 GCC have needed such a kludge?

BTW, your earlier allusion to MinGW having forked from cygwin is flawed;
MinGW never did fork from cygwin, (other than in the creation of MSYS);
the only reason mingw32 GCC accepted -mno-cygwin was because the cygwin
folks had it adopted upstream, as a standard option for WIN32 targets.

CPython's distutils mixes up the code for cygwin and mingw a
> little but the '-mno-cygwin' option is only used for mingw:
>

This makes no sense whatsoever; -mno-cygwin is only meaningful for
*cygwin*, to force its native GCC to redirect its activity so as to
behave as a wrapper for a mingw32 cross-GCC.

BTW where is the changelog ...


 I shouldn't need to say this; you can find it in the source
tarball for the current MinGW runtime (mingwrt) release, which *is*
available from our SF download pages, (and visible there).
Alternatively, you may just:

  mingw-get source mingw32-mingwrt

to download it via mingw-get, or:

  mingw-get source mingw32-mingwrt --print-uri

to see the download reference.

... and can it be viewed from the web?


Yes.


> I'm having trouble locating it.
>

Since we stopped hosting alongside cygwin, and merged mingwrt and w32api
into a common Windows System Libraries package, it has been moved to the
doc/historical tree of our WSL git repository:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/doc/historical/mingw/ChangeLog

-- 
Regards,
Keith.
 
CD: 3ms