delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1998/02/24/11:25:31

From: janjaap AT Wit381304 DOT student DOT utwente DOT nl (Jan-Jaap van der Heijden)
Subject: Re: Mingw32 Futures
24 Feb 1998 11:25:31 -0800 :
Message-ID: <Pine.LNX.3.96.980223222057.735A-100000.cygnus.gnu-win32@zoo-station.student.utwente.nl>
References: <199802210941 DOT BAA04960 AT smtp3 DOT teleport DOT com>
Reply-To: Jan-Jaap van der Heijden <janjaap AT Wit381304 DOT student DOT utwente DOT nl>
Mime-Version: 1.0
To: Paul Garceau <pgarceau AT teleport DOT com>
Cc: Colin Peters <colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp>,
GNU-Win32 list <gnu-win32 AT cygnus DOT com>

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.

> 	Since Jan-Jaap has been maintaining and updating this "extension", the 
> original mingw32 distribution is now capable of handling dx3 and OpenGL in 
> both C and C++ forms.  This "extended" version has been qualified as part 
> of the FSF packages.  It can also co-exist with cygwin32.dll without any 
> apparent problems so far.

I'm not aware of OpenGL capabilities :-)
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.

> > 
> > That is typical of the "problems" I am having right now. Basically, there
> > are at least three versions of the gcc compiler distribution which either
> > have or plan to have Mingw32 integrated into them. Jan jaap's Mingw32 gcc
> > 2.8.0, Mumit Khan's releases of EGCS for Mingw32, Cygwin32 gcc (perhaps
> > starting with b20) and maybe the FSF version of gcc.
> 

I don't focus on mingw32 (header) development. Every now and then I come
across a missing prototype, but I have always submitted them to Colin. The
only difference between mingw32 from my site and Colin's is a slightly
different directory layout, to easy installation. Since Mumit Khan and I
use nearly identical gas (binutils) snapshots, they should be binary
compatible.

> > 
> > I have no problem with this at all. I put that code in the public domain
> > so people could use it. However, I am basically the defacto maintainer of
> > the Mingw32 source base until someone tells me otherwise, and so my
> > questions are something like this:
> > 
> > 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?)?
> 
> 	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.

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.
> 

????

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".

> 	Here's a question for Jan-Jaap:
> 
> 	What is the status of the Mingw32 extension in regards to gcc/++ 2.8.1?
> 

I check gcc-2.8.1 pre-releases as they are released.
Right now, it lacks one patch to fix templates, but hopefully that's in
the mainstream sources before they are released.

Somebody from ACT (the Ada folks) changed the default from CRTDLL to
MSVCRT for 2.8.1. That would be an incompatible change, and I don't think
it's wise to make that switch now. And, I think Colin Peters should have
been the one to decide upon this. He said it himself: he's the maintainer.

But, I plan to upload a GCC 2.8.1 binary soon after it's release, if
that's what you mean.

> 	[Disclaimer:  I haven't followed EGCS near as closely as I have Mingw32.
> Even so, it is my impression that EGCS requires both the cygwin32.dll and
> the crtdll.dll in order to function properly, "out of the box".]
> 

Neither Mumit's, nor my GCC binaries, nor the programs they produce,
require cygwin32.dll.

> 	This would indicate to me that the best solution may be to issue three
> variations of cygwin32.
> 
>  a) Cygwin32 with Unix layer  (Cygwin32)
>  b) Cygwin32 without Unix layer (Minimalist Cygwin32)

The essence of cygwin32 is it's unix emulation layer with C library.
If you leave that out, you will have to find a replacement C library, such
as mingw32. But I'm not sure that still qualifies as "cygwin32".

>  c) Cygwin32, the ragged edge (EGCS)

No no no.
EGCS is "only" another compiler, and you could build cygwin32, mingw32 or
whatever unix version of EGCS, just like "plain" GCC.

There's a lot more GNU software, other than GCC.
If you want to put a compiler toolchain together, you also need make,
binutils, grep, sed, awk, gdb, a lot of libraries.....
If you like experimental compilers, you simply swap FSF GCC with EGCS.
You will have to replace your libstdc++ too, but the rest is basically
untouched.

I hope this clears up a few things, especially about compatibility.

JanJaap

-------------------------------------------------------------------------
J DOT J DOT vanderHeijden AT student DOT utwente DOT nl :                            At home
JanJaap AT bbv DOT nl :                                                  At work
http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32 : Mingw32 GNU site
http://www.bbv-software.com :             Solutions for Integrated Optics


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019