On Sun, 23 Aug 2009, Hans-Christoph Steiner wrote:
From my perspective, adding -lstdc++ has more problems than just making a simple libstdc++.pd_linux and loading that. For example, the Debian package will then require libstdc++.
Requiring libstdc++ isn't what I call a «problem».
If you mean the Pd-extended package that includes Gem... it already requires libstdc++ since a long time. I can't find an old Pd-extended debfile on my computer that doesn't list libstdc++ as a dependency.
maintaining it. Someone else would have to step up on that front. The libstdc++.pd_linux could easily be included with Gridflow. Or using the libdir format like Gem perhaps, where it loads a shared library first as part of the process of loading the lib.
Actually, I can't get the linking problem solved just by messing around with the GridFlow linkage. I can't seem to fix the problem by linking anything statically. It seems to be about whatever libstdc++ is started first, no matter whether it's linked statically inside a certain libGL, or linked dynamically from anywhere on the system. It boots the "try/catch" system used by the whole process, and then a "throw" compiled with a new gcc doesn't work with an old "try/catch" system, no matter how old is the compiler that compiled the "try/catch" commands. This is as far as I could guess what's going on.
The bug may come back in the future, but if you always load libdir and Gem at the beginning of the loadlib list, then it will not come back (or else, it would be a different bug, certainly!).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801