Comment 225 for bug 410407

> Is it a problem with GTK+ or ia32-libs?

The big picture here is that GTK+ changed the way it does certain things, intentionally and as an improvement. What should happen then is that every piece of software that relies on GTK+ would be updated to cope with/take advantage of the new stuff. And so it has happened with all FOSS projects using GTK+. However, nobody but Adobe can change libflashplayer.so, and they haven't. That is THE problem, and THE solution lies with Adobe.

Now, for workarounds. The GTK+ change came with the ability to revert to the old behaviour via environment variables. A possible workaround would be to modify web browsers (and everything else that uses libflashplayer.so) to set up their environment so that the GTK+ calls made from within the Flash player stick to legacy behaviour. Chromium (if the reports above are correct) has done this, others haven't. Remember that this situation is supposed to be temporary - one would expect Adobe to *eventually* fix libflashplayer.so - so it might not be worth for browsers to go through this.

Another workaround is applicable to 64-bit systems, where a 32-bit libflashplayer.so is used (this is sub-optimal, and again nothing can be done because of Flash being proprietary). The interface between the 64-bit browser and the 32-bit plugin is nspluginwrapper. The 32-bit plugin then uses 32-bit libraries (including GTK+), which are gathered in this thing called ia32-libs. By modifying the nspluginwrapper scripts, one can directly modify the environment under which libflashplayer.so is run, without need to modify the browser itself.

To answer your question, there is no problem with GTK+, there is a problem with Flash not being updated to cope with updates to GTK+. And ia32-libs simply mirrors the current versions of common libraries, it's not to be blamed either.