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