This is the mail archive of the
mailing list for the Cygwin project.
Re: merging mingw and cygwin
At 01:19 AM 10/12/2003, Edward Peschko you wrote:
>On Sun, Oct 12, 2003 at 12:27:06AM -0400, Larry Hall (RFK Partners, Inc) wrote:
>> At 10:01 PM 10/11/2003, Edward Peschko you wrote:
>> >> What would be the point?
>> >lack of end-user confusion... elimination of duplicate development effort... elimination
>> >of duplicate maintenance effort... the ability to compile all unix tools 'native' win32
>> >for those who desire it.
>> It's too bad you chose to edit the original context down to nothing. Your
>> response makes little sense now.
>Ok, the original context was 'what would be the point in merging the two projects.
>The answer is given above.
Right. And my answer is below.
>> If you don't want the two sets of tools, why did you install them? No
>> one told you to.
>well, that's not what the mingw docs suggest. They suggest to use cygwin to 'fill in the
>gaps'. Which is rather silly, because that doesn't work.
As I said, MSYS is a subset of the tools available in the Cygwin environment
and doesn't provide a POSIX API. I'm not going to debate the Mingw docs.
This isn't the forum for it anyway.
>> Use the tools that work for you. From your stated goal, I would say that
>> Cygwin tools would suit you best. But you should be able to get there with
>> either toolset, depending on your application and the amount of porting you
>> want to do to get it running on Windows.
>no.. the cygwin tools don't suit me best if there are unixisms in the executables I
>and dlls I create, or if they require a POSIX sublayer. Ultimately, I'd like to use
>whatever executables I get out of cygwin in conjunction with VC++ and third party
>win32 APIs. (horrors!)
I'm sorry. Who said this couldn't be done with either Cygwin or Mingw?
You're seeing issues that don't exist. I guess I wasn't making that plain
enough for you. In the general case, you can build your app with Cygwin
(-mno-cygwin or not) or Mingw and run it however you like, integrate it
with whatever you like, and use it however you like. Does that eliminate
>I want to develop native win32 applications on unix. I don't want to use the POSIX
>emulation layer. But I do want to use unix tools to do my development. I also want to
>make sure that any scripts, makefiles, what have you don't create constructs
>which native windows applications find annoying. (so far I've found one such construct;
>'directory' links as shortcuts; you can use junctions on winnt+ which are *much* better)
Well, if you're creating your own application build environment for your
"project", you don't have to use shortcuts if you don't want them. The
fact that some random Windows applications don't handle them well is a
problem for that application or with the Windows environment itself, not
the Cygwin or Mingw toolsets. But this is all getting highly conjectural
again so let's put this line of discussion to rest here.
But again you're confused. Neither Cygwin nor Mingw/MSYS are UNIX. They
don't run there. They're not needed there. And if you are building an
application on UNIX and want to bring it to Windows with minimal porting
effort, POSIX will be *very* important for you. But I don't think that's
what you want to do anyway. So you statements above are conflicting.
You need to move from the theoretical and into the practical. Pick one
of these two sets of tools and start working with them. Use them to do
what you're trying to do. If you find a problem, research for the answer.
If the toolset you picked can't do what you want, look at the other. I
think you'll find you have what you need. If not, at least at that point
you'll have a specific, concrete need that can more readily and directly
>> You don't understand what the main difference is between Cygwin and Mingw
>> do you? Have you checked? OK, I'll tell you. Cygwin provides a POSIX
>> emulation layer (I assume that means something to you if your stated
>yes, I understand all of this.
>> goal of bringing something from UNIX to Windows is actually what you want
>> to do). So this generally lowers the burden of "porting" packages to Win32.
>> With luck, the code base compiles and runs without change. I think you can
>> understand the value in that, right? You don't get this with Mingw. You
>> don't get this with MSYS (see
>> <http://www.mingw.org/mingwfaq.shtml#faq-msys>). So what you suggest
>> really doesn't make sense in the context of Cygwin in terms of just plain
>> generating binaries from traditional UNIX source packages.
>yes, I understand this too.
>> >This whole cygwin/mingw split reminds me a lot of egcs vs. gcc... and
>> >I think that the same reasons for merging apply here.
>> The fundamentals between the two projects (Cygwin and Mingw) are different,
>> despite the fact that they both target Win32 as the output of their build
>> tools. The difference is that Cygwin provides a POSIX API and the resulting
>> binaries are subject to the GPL (please don't let this be an opening to
>> start a debate about the GPL). Mingw only provides a toolset to support
>> configuring source to build via gcc on Win32. It has no POSIX layer (unless
>> you consider MS's API a POSIX layer). It uses MSVCRT as its C runtime. So
>> there is no GPL license affecting the binaries that result. But the tools/
>> utilities provided with Mingw (and MSYS for those that want them) are
>> really a subset of the tools, utilities, and applications that come with
>> Cygwin. Now, if you're claiming that MSYS, which resulted from a fork of
>> the Cygwin DLL some time ago, is what needs to be merged with Cygwin (or
>> vice-versa), one could argue that (I'm not) but you should be pursuing that
>> on the Mingw list, not here. This list can't prohibit forks of the Cygwin
>> DLL code any more than any other GPL'd project can prohibit forks of their
>> own code. And we can't force a merge of the code back even if we wanted to,
>> if that's your point. But since I don't really know whether this is your
>> main idea/complaint or not, the discussion of it is highly speculative and
>> not very worthwhile. If this is your point of interest, take it up with
>> the Mingw folks. But first, make sure you understand both projects well
>> enough to discuss them well.
>If this is the case, how do you create native binaries for Win32 under cygwin?
>Wouldn't -mno-cygwin, under your argument, create binaries that are not GPL compliant?
>Or does 'no-cygwin' require some other emulation layer that you haven't talked about?
>Anyhow, at some point you've got to link with the windows runtime..
No, you don't for Cygwin. Cygwin's DLL is the POSIX emulation layer plus C
>And come to think of it, why do you care if the *binaries* are GPL in the first place?
>GPL is about source, right?
Some people care because they want to hoard the source.
>My main idea/complaint is that there are two separate sources for gcc/ls/rm, etc. They
>are at different rev levels, and vanilla source code from gnu.org does not build
>cleanly under both cygwin and mingw.
A specific example here of build problems with vanilla source would be
useful. Too much hand-waving harms any argument. Still, I believe
I've addressed this issue already by stating that there are sometimes
Cygwin-specific patches that are necessary but that they are generally
pushed upstream ASAP. You seems to be implying that this is a wide-spread,
debilitating problem. You'll need to provide evidence of such a sweeping
>If -mno-cygwin creates binaries that are native win32, without posix layer,
>and that use the MSVCRT as its C runtime, then the projects are for all intents and
>purposes, merged because '-mno-cygwin' is a synonym for mingw. There would then be two
>steps in porting any unix package:
> 1) making it work with cygwin (ie: without -mno-cygwin)
> 2) making it work under -mno-cygwin
>As you say, #2 would be more difficult because you couldn't use the POSIX layer. But its
>doable, and has been done many times. The completion of the port would be to have all
>applications that cygwin supports win32 native as well and have the patches to make them
>win32 native as compiled by -mno-cygwin put into the standard distributions.
>Right now, that's done in bits and pieces. Xemacs here, perl here, BerkeleyDB there..
>unxutils (unxutils.sourceforge.net) provides yet another group of native utilites, and
Right. It could be done, at added initial and on going maintenance cost.
And in at least some cases, this would be of little value. The main
reasons for doing this is to improve performance (by eliminating the logic
of the emulation layer) and/or to get out from under the GPL. Since GNU
packages are already GPL, the latter is not much of a concern for packages
that go into the Cygwin distribution. The former is sometimes a goal/need.
But porting directly to Win32 isn't the only way to solve it. So I don't
see all packages doing this. But, as you say, it could be done.
>And all of these are done separately, so of course no integration testing is done to
>make sure that these work together well..
>*That's* the main point behind making cygwin create a set of tools native to win32; right
>now, the effort for windows/unix is fragmenting, chaotic, and there's no central qa to
>make sure that individual porting efforts work together. In any case,people seldom
>release the patches that they made in order *to* port the given project, or if they
>do, they get lost. And as said the executables that result seldom work with
>executables created by someone else. And they use inconsistant tools (compilers, etc)
>to *create* these tools and libraries, so any integration with third party APIs becomes
OK, if that's your opinion but I don't see any facts that corroborate that
view. You'll need to find something more concrete to base this kind of
discussion on if you want to continue with it on this list. Of course, if
your goal is to simply state your piece and move on, that's fine too. You've
>> The way this works is someone volunteers to be the Cygwin maintainer for
>> a package they'd like to see in the Cygwin distribution. Cygwin is
>> an open-source, volunteer-driven project rather than the more typical
>> customer-driven commercial products you may be used to. If you want
>> something done, the quickest way to make it happen is to contribute it.
>yes, I am aware of open source. yes, I was giving a suggestion. No, I don't know
>how to 'contribute it' except to note that it is there for someone who handles central
>distributions to go pick up the tar ball and run with it. It should be as simple as
>underneath a cygwin shell.
It is so now in general. The problem is seldom getting the package built.
But building is just the start. As you mention above, there are new versions
to think of, testing to do, bugs reports to handle and fix, coordination with
the maintainer of the general package, etc. Cygwin doesn't include tools in
it's distribution that don't have someone to fill this role.
>Someone who has access to the maintenance of setup.exe
>could probably make the prerequisite changes faster than I could.
Ah, OK you've lost me again with that statement but I suspect it's not
terribly important since you don't seem to have any interest in following
up on this.
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html