I'm in shock. Amongst other emotions that I'm still trying to figure out.
I came into work this morning and checked my e-mail to find that Danny Smith from the MinGW project had sent an e-mail "Bye" to the mingw users and developers mailing list. Bye? What do you mean bye?! Just as I was getting excited about the future of MinGW with it's spanking new modern compiler, the only guy working on it has quit. I don't know what to think. Is it a bad joke? Has someone broke into his e-mail account and sent the message. The responses from the other MinGW developers leads me to believe not as they politely wished him well in his future endeavors as well as expressing their fear for the future of the project.
And fear we should. I was always concerned over the lack of progress with the MinGW compilers. The seemed stuck on 3.4.2 as the official release for a long time (and now, probably even longer). Danny had come to the rescue and offered hope that the wait was over and we'd soon be able to enjoy all the great improvements to gcc in recent years. But now it appears someone else will need to take on this challenge. And it appears to be a big challenge as there were a number of bug reports flowing in (one of which was mine) and I was getting worried that Danny would get overwhelmed.
The timing of this is interesting, especially after my blog entry yesterday. But I've also been in a number of discussions in Eclipse lately over the need for diversity for projects to succeed. If contributors to a project all come from one company, what happens to that project when the company needs those resources elsewhere. The CDT was able to survive such an incident because we had contributors from many organizations who stepped up to fill in the holes (and I still can't thank them enough :). But there are projects at Eclipse who haven't worked hard enough to make sure they diversify like this and it is something to worry about if you rely on such projects.
And that's the position I find myself in. I was relying on MinGW's 4.2 compiler to make Wascana a super appealing environment for Windows development, even for commercial use. Now, I'm not sure what I'll do. Maybe it's time to apply some focus again on the Windows SDK compiler and debugger integrations. Although, unless by some miracle Microsoft let's me redistribute their SDK, it violates Wascana's primary mission as a simple to install complete IDE. And I doubt I would have ample time to contribute to MinGW and I don't really have the expertise anyway. And I have QNX work piling up. And CDT stuff to prepare for. Like I said, I'm still trying to figure this whole thing out...
I don't like to sound preachy, but I agree with you. In my last post... I said, "Building a successful open-source project is about building communities and relationships... that trumps whatever bug you're working on at the moment."
ReplyDeleteThat can sound harsh... but I wholeheartedly believe it's true. If you don't have a good group of diverse contributors and committers, your project can die overnight. Look at what happened to the VE folks...
Diversity and welcoming new contributors is what has allowed most of the great open source projects to survive. But it's a tough line to walk in a commercial open source community like Eclipse where projects tend to be driven more by the market goals of a single member company. One member company may benefit the most from keeping tight control over a project's committers and contributors but the community of all members benefits more from diversity. Especially for some of those core projects upon which everyone relies...
ReplyDeleteIf you can't achieve the ideal, settling for something close might do the trick just as well. Let's face it: Microsoft's C++ compiler is a pretty good one, their Windows support is... well, it's their OS, their debugger is not bad either; all in all, not a bad development platform to rely on. Yeah, it's not open source, and it will mean having users install two (or three) packages instead of one. But if the alternatives are worse from a technical point of view, I'd take this solution without a second thought.
ReplyDeleteAfter all, we're talking about technical users, even if they're hobbyists. As long as they only have to go through a few well documented installation steps, I can't see how anybody could object to such a pragmatic approach, when the end result is a top-notch development environment, without all the limitations of Microsoft's free (and even paid) offerings.
I'm definitely leaning towards MSVC support. The Windows SDK is a 1.2 GB download but includes everything. I'm not sure how they get Visual C++ Express down to 60. But supporting that could even be an option.
ReplyDeleteI'm sad for the state of MinGW. It has so much promise, but with so few contributors, it's an unsustainable project. I just read a note on mingw-users where a small business was relying on it and now is screwed since they have a bug and no one to fix it. They've had to move their Windows stuff to VC++ Express.
It *may* not be time to panic, yet:
ReplyDeletehttp://cygwin.com/ml/cygwin/2007-08/msg00830.html
We'll just have to wait for more information from Danny.
Oh, and you're sorta overstating the issue with that small business. He first posted a message on the issue 13 Aug 2007 -- but "I am loading a ton of DLLs and it's really hard to reproduce this with a small example."
ReplyDeleteSo, without a reproducible test case, it's unsurprising that no one was able to help. A few days later, a new thread led to some interchanges. That thread was advanced every few days as more information became available. However, due to deadline pressures, the OP had to deliver something to his customers sooner, so when it became clear that there was no quick fix, he made a temporary switch to MSVC.
Expecting ANY open source project to be able to fix a bug -- especially one that is apparently as complex as this one -- on a corporate "by our product's planned release date of next Tuesday" is just silly. (Actually, expecting any vendor -- open source, volunteer, or commercial -- to do that absent some contractual requirement is silly. Is Microsoft going to fix a compiler bug in visual studio on YOUR production schedule, or on their own?)
Further, even after releasing the MSVC-compiled version of his product, the OP has returned to the problem and there was another flurry of activity tracking down the mingw bug two days ago.
There is a reply from Danny on the mingw-dvlpr list. It's short and doesn't really explain anything but is a second message from him confirming 'bye'.
ReplyDeleteAnd, yeah, I'm probably being alarmist with the small business guy. You have to wonder why the guy was switching compilers so close to a product release anyway.
But this turn of events does nothing for the concerns I've always had about the gnu tools for Windows development. There just isn't enough investment in them.
Agreed.
ReplyDeletePart of that is because compiling gcc on windows [mingw or cygwin] is HARD, compared to other open source projects, and time consuming. On my machine, a full cygwin bootstrap with tests, takes almost three days -- far longer than any other package distributed by cygwin. Worse, in the 3.4.x days there was NO documentation on exactly how "our" source code differed from "stock" CVS -- and never mind that "stock" CVS might refer to mainbranch 3.4.x or the separate cygming 3.4.x branch! Nor were the exact configuration options used to compile the official cygwin or mingw gcc packages documented anywhere...
Not really the best model of open source development, and with the advent of gcc 4.0, it bit us. Bigtime.
The ability to throw exceptions and catch them across the "DLL boundary" is fundamental to proper C++ and Java operation. That ability, in 3.4.x, relied on a cygming-specific hack in the gcc source code -- which meant that the ABI for "stock" gcc on cygwin/mingw differed from that of the official gcc packages released by the cygwin and mingw project teams.
But that hack was intimately tied to the 3.4.x internals -- internals which were completely changed in 4.0. Further, the cygming-3.4.x branch was never merged back into the main 3.4.x, nor were any of its modifications merged directly into the ongoing 4.x development. So, the "hack" had to be rewritten from scratch, or another solution found.
Danny wrote that original patch, and often stated that he would not, and in his opinion nobody should, port it to 4.x -- because the better solution was to build the runtime libraries as DLLs, which would fix the "exceptions across DLL boundaries" problem organically.
For more info, see
cygwin ml post
I had hoped that with
(1) the upcoming 4.3 release and the promotion of mingw to a "secondary" platform gcc ml post
(2) finally getting modern (cygwin- and mingw- friendly) libtool support into gcc newlib ml post
(3) Danny's recent work with shared libgcc and libstdc++
mingw ml post
that those issues were soon to be resolved. Certainly the (fortran-focused) gcc developer FXCoudert is pushing ahead:
gcc-patches ml post
We'll just have to wait and see how it shakes out -- or dive in and help the shaking.
Thanks, Charles. That helps me understand the situation. Moving mingw to an official status with the gcc main line would help a ton. I'm hopeful now that things will work out. And as you said Danny didn't inform gcc of his decision. Maybe he's going to move his work there.
ReplyDeleteDoug, on the issue of getting from the 1.2 GB of the SDK to the 75-something MB for Visual C++ Express: the latter is not a complete, standalone IDE for Win32 development. It only allows you to do .NET development right out of the box; to write native Windows code, you need to go through a few more steps, one of them being installing the SDK, as outlined here.
ReplyDeleteThere's just no way to squeeze all the SDK into such a small package; of those 1.2 GB:
-64% are documentation,
-16% are samples,
-6% are API include files (75 MB by themselves).
Obviously, none of these are included in the VC++ Express package.
To make things more interesting, there's also some very useful documentation that's included with VC++ Express, but not with the SDK: the reference guides for the language, compiler, and standard libraries.
Can it get any messier than that?
Yeah I just checked that. Express doesn't even include windows.h. The other thing I just found out with the latest Windows SDKs, there's no Debugging Tools for Windows with it any more. So you'll have do download it separately too. And Express comes with it's own implementation of dbgeng.dll. So, yeah, it can get messier :)
ReplyDeleteHi Doug,
ReplyDeleteThis is the guy that had to do the last minute MSVC build because of the MINGW bug.
Thankfully with the help of Brian Dessent, Charles Wilson, and Danny Smith the bug has been tracked down, and I can now work around it. Everyone really did an outstanding job helping me and I think that the whole ordeal was a testament to how open source CAN work. I have not lost any faith in MINGW, and I hope the project can continue to grow.
I honestly never expected anyone to fix anything for me. I am willing to take my spare time and track down the problems myself if I need to. It was really nice having people on the mailing list that could guide me through the parts I didn't understand.
The build I had to perform was an internal one that had some very important features that we can use here to save some labor costs. We develop on Linux, using the CDT, and GCC, and compile to a few other platforms. Therefore, I stick to standard C++ and I don't use any extensions. This is why I was confident I could get an MSVC build out internally and then still have time to track down the problem with MINGW. Everything worked out as planned.
No matter what happens, I'm not giving up on MINGW. As long as there is a glimmer of hope, I'm willing to put in my time to help the toolset that has helped us more easily port our software to other platforms. It is the least I can do.