This is the mail archive of the
mailing list for the Cygwin project.
Re: Mingw32 Futures (Classification)
- To: pgarceau at teleport dot com
- Subject: Re: Mingw32 Futures (Classification)
- From: "Bartlee A. Anderson" <banders at ECD dot Rockwell dot COM>
- Date: Thu, 26 Feb 1998 13:06:15 -0600
- CC: gnu-win32 at cygnus dot com
- References: <199802210941.BAA04960@smtp3.teleport.com> <199802251105.DAA13839@mail1.teleport.com>
What do we call egcs then? It uses gcc as well. I think we need an extra
field. Or can we differentiate implicitly by the version numbers?
Enquiring minds want to know ;)
Paul Garceau wrote:
> On 23 Feb 98 at 23:34, the Illustrious Jan-Jaap van der Heijden wrote:
> > On Sat, 21 Feb 1998, Paul Garceau wrote:
> > > >Many posters refer to "Mingw32 2.8.0" which is
> > > > actually the GNU compiler gcc version 2.8.0 built by Jan-Jaap using the
> > > > Mingw32 headers and distributed bundled with those headers. I'd call that
> > > > Mingw32 gcc 2.8.0.
> > Personally, I have always used terms such as "mingw32 gcc", "mingw32 GNU
> > software" etc., just to avoid this kind of confusion.
> (skip OpenGL references)
> > Seriously: work has to be done before mingw32-gcc can fully utilize the
> > possibilities of the Platform SDK. This includes modification to
> > binutils, and an easy, upgradable way to patch the SDK headers.
> > > I am not sure where Mumit Khans' version fits in here, though I
> > > understand that EGCS is supposedly considered the ragged edge of cygwin32.
> > Not quite.
> > EGCS is a vehicle to speed up the development of new features for GCC.
> > Mumit Khan and I swap patches every now and then, so as far as mingw32
> > related features are concerned, the compilers are more or less equal.
> Thanks for the clarification, Jan-Jaap.
> The Illustrious Colin Peters wrote:
> > > > 1. Mingw32 is basically a C run time library replacement. As I understand
> > > > it gcc is usually bundled with the GNU C library (libc and libm) among
> > > > other libraries. Cygwin32's newlib is similar (with a more ambitious
> > > > goal). Has anyone seriously thought about how this should fit together?
> > > > If *I* thought about it who would I need to talk to about implementing it
> > > > (newsgroups? mailing lists?)?
> Paul G. wrote:
> > > The most recent information indicates that gcc/++ 2.8.1 will have the
> > > mingw32 headers, etc. (basic Mingw32 distribution) completely integrated
> > > as well as full compatibility with the Cygwin32.dll by simply including
> > > the cygwin32.dll in the distribution.
> Jan-Jaap wrote:
> > Nope.
> > GCC (sources) do not include any C library component, nor libstdc++
> > However, all essential support for i386-mingw32 or i386-cygwin32 targets
> > is in the regular sources, so no patches are required to build the
> > compiler. A few patches exist, but they are bugfixes.
> > > Mingw32 would not exist if Cygwin32 did not have some sort of previous
> > > existence prior to the Mingw32 (v0.4) date of availability.
> > >
> > If it was not for the PE-COFF support implemented by the Cygnus' people,
> > mingw32-gcc would not exist. And Colin Peters started with a hacked
> > cygwin32 toolchain, if I remember correctly.
> > > Apparently EGCS requires the "basic" Mingw32 distribution as authored by
> > > Colin Peters. The "extended" Mingw32 distribution, as authored by
> > > Jan-Jaap, requires the "basic" Mingw32 distribution in order to function
> > > properly as far as I can tell.
> > >
> > ????
> Sorry for the confusion, I was attempting to categorize things since
> that's what I thought Colin was asking for. My mistake.
> > I did not extend mingw32. I have no plans to touch the essentials of
> > mingw32. I fail to see why "my" GCC should be "extended" and Mumit's
> > "basic".
> I don't believe that Mumit's is the "basic". If there is a "basic" it
> would be Colins' Mingw32-headers.
> I classify Mingw32-gcc-2.8.0 as an "extension" of Colins'
> Mingw32-headers by nature of the fact that Mingw32-gcc-2.8.0 would not be
> functioning as it is without Colins' headers. Thus, my definitions of
> Mingw32 are functionally oriented as opposed to process oriented.
> Mingw32-gcc-2.8.x software requires Colins' Mingw32-headers.
> Mingw32-gcc-2.8.x then takes those headers and integrates them with
> gcc-2.8.x or visa-versa.
> Therefore, and imho, Mingw32-gcc-2.8.x is equivalent to adding gcc-2.8.x
> to the Mingw32-headers and redistributing both as a unique package,
> distribution or toolchain.
> The above process tends to clearly define exactly what Mingw32-gcc-2.8.0
> functionality actually is and may serve as a means to allow us to classify
> Mingw32-gcc-2.8.0 in a much clearer and more concise manner.
> Paul G.
> Nothing real can be threatened.
> Nothing unreal exists.
> For help on using this list (especially unsubscribing), send a message to
> "email@example.com" with one line of text: "help".
Bartlee A. Anderson System Test (Interfaces-Tools-Automation-ISDN)
Rockwell International Electronic Commerce Division
300 Bauman Ct. firstname.lastname@example.org
MS 933-605 Opinions my own, not Rockwell's VOICE (630) 227-8975
Wood Dale, IL 60191 FAX (630) 227-9771
For help on using this list (especially unsubscribing), send a message to
"email@example.com" with one line of text: "help".