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

Mathieu Bouchard matju at artengine.ca
Thu Oct 15 22:05:48 CEST 2009


On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:

> sorry for the confusion. with "random linkeage" i was referring to e.g. 
> Pd-extended or 3dp linking with "-lstdc++". these are pure C (any 3dpers 
> forgive me, if 3dp is actually written in C++; i assume it is not), and 
> should, imho, not link against stdc++.

Well, all those shouldnots are somehow supposing that anything else that 
shouldn't happen is not happening. So in the end we get stuck with 
everybody else problems AND a long list of all the solutions we shouldn't 
use. So in the end, we end up having to tell the users to not move Gem 
away from the top of pdsettings/pdrc lest they pay the price for it, when 
there are more global solutions for it that could fix the problem forever. 
I wouldn't really advocate that 3DP or whatever else would link to 
-lstdc++ because then it doesn't fix the problem that people just can't 
reorder their pdsettings/pdrc lines as they please. So I'd rather link pd 
itself with libstdc++, and although it doesn't make any sense when trying 
to follow all rules, it does make perfect sense when you consider that to 
compensate from rules that have been broken you may as well break more 
rules. The problem is with a variable that is global to the whole pd 
process anyway, so with a certain logic, pd itself is the right place to 
fix the problem.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801


More information about the Pd-dev mailing list