In recent weeks, I've been mainly confined to using my MSVC compiler setup to compile Blender, leaving me by and large without a easy-to-use and readily-available debugging environment. A change or set of changes (which I haven't been able to track down yet, but which were probably related to work to upgrade some precompiled-libs we use) suddenly started making ld (gcc's linker) to start refusing to do the final linking of the binary, as it'd fail with some internal error.
However, tracking down bugs in the bugtracker (for 2.5) is a bit more challenging without a working debugger to pinpoint where segfaults are coming from. Thus began the quest for a potential "upgrade" to my trusty mingw setup to hopefully get it back working...
A bit of background info... (a rant over MSVC vs mingw-GCC/GDB)
I personally prefer the simplicity of debugging crashes offered by gdb+mingw(gcc) builds over the IDE-style popularised and enforced by MS's offerings. For many years I've used the gdb+mingw combo to great effect, and for quite a few years was really my only choice (MSVC just wouldn't even install, and if it did, it would probably be too much of a resource hog).
One really nice feature was that gcc builds straight out of the box (i.e. plain 'release' builds) could usually still be approximately 'debugged' using gdb; that is, I could get a backtrace with the (stack of) function names where the program crashed, which is 90% of the time sufficient for catching crashers as quick code inspection will reveal the problem (and only if that wasn't sufficient, you'd then have a general pointer to where the problem was, and could attempt a partial debug build of those parts only, saving time+effort). With MSVC (and similar), you'd have to compile a debug build (which takes a long time) or always use debug builds only (a risky strategy, as some bugs will be masked by this approach too, not to mention longer build times, and slower code to test), or else you'd just get assembler crap out of it (which for me at least is totally useless and pointless).
Another key benefit of gcc builds is that you aren't tied to working your project in some IDE. One key problem is that with MSVC, unless you have projectfiles set up (maintenance, clunkiness, and long waits for (not-so-)Intelli-Sense to get its act together after each compile) you really don't have any hope of debugging crashes on startup. If you compiled your program using scons (or your own hand-brewed buildsystem), you can only get MSVC to debug it in post-mortem style (i.e. when it has crashed), or by a tedious process of attaching a process/instance of it that you manually initiated, EVERY SINGLE BLOODY TIME YOU WANTED TO DEBUG (with projectfiles, it is possible to get MSVC to run the program for debugging, and it will stop properly, but I've had huge troubles trying to get proper command-line args to get passed in some cases this way). On the other hand, gdb allows you to start it with the program as an arg, then run the program ('r') and grab backtraces ('bt') when it crashes, with no additional complexity unless you asked for it.
Speaking of complexity of the debugger, MSVC's approach debugging info displays is IMO very confusing. A lot of the time, it presents far more information than you really need most of the time, not to mention that at times it gets difficult to understand where the information state shown is valid. In contrast, gdb only gives you what you want to know, and when you want to know it, and it's predictable what is shown.
Additionally, having worked a bit with the MSVC code editor a bit recently, I would have to say that IMO it is seriously overrated; Notepad++ (4.6 and older only. Newer versions have gotten crappy) or Geany (0.18 or 0.19 or newer. Older versions were less polished) are much better aligned with the way I like to code (and see my code), but that's better left for another day.
A quest through the fog...
It's been many years since I'd last tried installing or upgrading mingw. Back then, it was a relatively easy setup process, with a really light footprint (both download and installed) compared to MSVC (with it's hunger for diskspace, memory, and recent MS-product-filled-environment) which was quite problematic. A simple installer would download all the components you'd need and install them, and with a few manual path tweaks yourself, it was ready to go.
Sadly, it seems those days are long gone.
Back when I set up my mingw setup on my primary development machine, mingw was still using gcc 3.4.5. However, in Linux-land, the winds of change were already blowing, albeit lightly at first, as gcc 4.x was already starting to see the light of day in those fields. Actually, maybe I'm getting confused with the history now (bah! history! bleh! */me vomits from boredom*) but there was talk even back then about upgrading mingw's gcc to the 4.x series. And back then, the general consensus was that there were some technical difficulties - there was now some stuff that'd need to get ported differently and/or may cause strange issues to appear in new builds.
Several years passed. From time to time I heard/saw in passing that mingw was still officially only supporting gcc 3.4.5, but that there were now high-unstable, unstable, gcc 4.x nightly-builds/ports showing up on "tdm-dragon" or so site. However, apparently these were so useless that they would cause all manner of wrongly compiled software that they weren't worth touching. At one stage, the mingw site even went offline for a few months! And thus, this was the holding pattern for the next few years...
As recently as 2 months ago, I started checking back on mingw as occasional changes would start bringing down my compiling system from time to time. At that stage, all sources were still claiming that the "latest stable version" was still gcc 3.4.5, and that the tdm-builds were still unreliable, though others were starting to recommend using it. This was probably reflected in increasing numbers of (Blender) users were starting to build with gcc 4.x on windows, mostly without incident, apart from a few very nasty compiler crashes under certain modules (fluidsim being one of them).
Shadows of the past...
Yesterday I had another look at the mingw site hoping to try and upgrade my mingw system, since it still couldn't link.
For the first time in years, it looked like "change had come". Wikipedia reported that the latest stable version was gcc 4.4.0 (or similar). And certain parts of the mingw site also seemed to suggest this. However, it quickly became obvious that trying to install that new version was no longer the nice and easy process it had been all those years ago.
The 'automated installer' was looking more and more broken: the old version I had refused to work, claiming a newer version was available; but the newer installer only showed duplicate entries (with some entries completely missing), with an overall broken-down/useless look.
There was also now a "mingw-get" installer that was in "alpha" stage. Looking at the docs on using it, it looked like it was trying to imitate "apt-get", and would still require some manual unzipping work after being run. Further investigation also suggested that it was the only way to get gcc 4.x running, but that to do so, you'd need the special script, and potentially modify that script before use to point to the latest paths.
Ugh! Where did the easy setup go? It looks like the mingw project is now run (if you could say that... it's more like left-to-rot-and-decay) by a bunch of buffoons with really no plans other than finding something to "hack in their spare time".
The new way?
Disgusted, I stumbled again across the alternative supplier of mingw-like environments: http://tdm-gcc.tdragon.net/
Surprisingly, this was offering seemingly nicely presented setup bundles with gcc 4.x now, with a really clearly laid out download section. Wow... unstable test builds to this?!
---
Currently, I'm still trying to ascertain whether the packages offered here are indeed useful/stable. Anyone know if this is really the case?
(I also have to wonder if this is really a fork of the mingw project by those member(s) that were dissatisfied with the non-progressive, and even backwards treading direction of the project...)
No comments:
Post a Comment