Subject: Re: Mingw32 Futures (Classification)
From: [email-masked] (Bartlee A. Anderson)

6 Mar 1998 02:32:09 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [email-masked]
Cc: [email-masked]

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 ;)
Bart
Paul Garceau wrote:
> 
> Greetings,
> 
> 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.
> 
>         Peace,
> 
>                 Paul G.
> 
> Nothing real can be threatened.
>     Nothing unreal exists.
> -
> For help on using this list (especially unsubscribing), send a message to
> "[email-masked]" with one line of text: "help".

-- 
Bartlee A. Anderson     System Test (Interfaces-Tools-Automation-ISDN)
Rockwell International                    Electronic Commerce Division
300 Bauman Ct.                                [email-masked]
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-masked]" with one line of text: "help".