Easier way to avoid dependencies on the system installed libraries

When you build wxWidgets under Unix, configure script will by default try using the system versions of the third party libraries, such as libpng, libjpeg, libtiff and so on. Usually this is the right thing to do, as you avoid compiling (potentially a lot of) code which already exists in the ready to use binary form on your system and, more importantly, use exactly the same version of these libraries as other libraries wxWidgets links with, notably GTK+ ones.

However, sometimes you may want to avoid using the system libraries, e.g. because you want to build a statically linked version of your program with as few dependencies as possible. This was always possible by explicitly disabling the use of each and every library with -with-libfoo=builtin, but this was relatively tiresome and it was easy to forget a library or two.

To remedy this, I've just added a new --disable-sys-libs configure option which does exactly what it says: when it is specified on configure command line, only the built-in versions of the third party libraries will be used. This can be useful in the above mentioned static linking scenario under Linux but is probably most valuable under OS X where you never want to have dependencies on any locally installed (e.g. via Homebrew or MacPorts) libraries as this would make the resulting binary impossible to run on other OS X machines.

To summarize, it's a tiny feature, but one which would probably go unnoticed in the 3.1 release change log while I think it could be something useful to quite a few people.

"Invalid parameter" debug messages when using wxGLCanvas

While debugging a problem with wxGLCanvas today, I noticed that every run of the OpenGL cube sample resulted in several copies of the following message in the MSVS debug output window:

Invalid parameter passed to C runtime function.

Now this is an error message just as I love them: it's worrisome enough to make you feel like you ought to do something about it, but without any information allowing you to find out what, actually, should be done. Luckily, there are not that many ways to write to the debug output under Windows and putting a breakpoint on OutputDebugStringA() (surprisingly used instead of OutputDebugStringW() that I tried first) discovered that the debug message was given from deep inside GDI ChoosePixelFormat() function which ends up calling wglChoosePixelFormat() in opengl32.dll which, in turn, calls into ATI driver DLL (atioglxx.dll) which ends up calling _wcscpy_s() with a NULL parameter which is clearly a bug, but it's not our bug.

So, finally the problem is not related to wxWidgets, even if you will see it every time you use wxGLCanvas with (this, buggy, version of) ATI OpenGL drivers. But at the very least I now know that if I see this message again, I can set a breakpoint on {,,msvcrt.dll}__invoke_watson function, using MSVS debugger idiosyncratic syntax, and directly see where does the problem occur. Hopefully this can be useful to someone else too and maybe it will save you some time chasing bugs in ATI code.

Ah, and the original problem which started all this? It turned out to be bogus. Today hasn't been very productive so far...

Some kind of a record

Today we closed two bugs in wxWidgets. Nothing surprising so far, except if you look at the bug numbers and realize that they are two thousand something while the latest ticket in the Trac is 16379. And these bugs were both opened more than 9 years ago, in February and May 2005 respectively. I'm sure that the fact that we are fixing bugs 10 years later must mean something, I'm just not sure what exactly. Do we not care enough about bugs to fix them so late? Do we care very much about them, enough to still fix them after all this time? Are we hopefully short on resources? Are we just very good at allocating our meagre resources efficiently so as to combine both bug fixing and still making some progress (which would never happen if we decided to not add any features until all existing bugs are fixed)? All of the above?

One thing is clear though: please keep reporting bugs in wxWidgets and if they seem to be ignored, know that there is always hope that they will be fixed one day. Next status report coming in 2050...