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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
