[PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM

[Mathieu Bouchard]

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