This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: merging mingw and cygwin

Ed said:

> Like I said, try:
> mingw > gcc -dM -e -xc /dev/null
> cygwin > gcc -mno-cygwin -dM -E -xc /dev/null
> cygwin makes 73 defines, mingw makes 38. If a large project uses any of the
> cygwin defines, it will behave differently than if compiled with native mingw.

That's because you used gcc-3.2.3 with mingw (3.3.1 is still a release
candidate  "over there") and gcc-3.3.1 with cygwin. I agree: A program
compiled with gcc-3.2.3 will be different than one compiled with 3.3.1.

So maybe you should harass the mingw list to update the release status of
gcc.  On second thought, don't do that. I hear they are petty mean over
there, too.

> As I said, this is just the tip of the iceberg - who knows what patches that
> mingw has made to gcc, ld, make, etc. which could affect the building and
> running of large win32 packages.

I do.  So does Chris, So does anyone who cares to look. The diff for gcc and
binutils is not an iceberg.

> If the large packages built in mingw are tested via mingw, then mingw is the
> only real way to a 'proper' win32 executable. And the only way to truly 
> emulate mingw32 would be by merging it.

Wrong.  I can build binutils for mingw with cygwin  gcc -mno-cygwin. It
is the same as the binutils that I build with mingw.  I have built a mingw gcc
with cygwin gcc -mno-cygwin. AFAICT, it is the same as the gcc I build with native
mingw. I don't do it any more because I like to say that I can do a native
bootstrap of gcc for mingw (with the help of cygwin tools)

> > Maybe the MingW package in Cygwin needs to be updated, however, I fail 
> > to see the need for a MINGW or NO_CYGWIN flavor aside from what 
> > currently exists (i.e. -mno-cygwin).
> Because gcc is not the only place that has MINGW-isms in it; msys departs from
> the cygwin standard and handles certain things differently.

msys != mingw.  mingw doesn't need msys.  Cygwin provides a more complete
building and testing environment than does msys.

> In order
> to build MinGW packages right, the underlying tools have to work the same
> as well.
> MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly
> package.

cygwin is a nice user friendly package. I won't speak for mingw because
I have a personal bias.


> Ed
> - Yahoo! Search
- Looking for more? Try the new Yahoo! Search

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]