Mathieu Bouchard wrote:
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
i still believe that this is something that is not to be fixed with hacks, e.g. random linkeage against stdc++. instead it should be fixed somewhere upstream, be it gcc, binary drivers or whatever; btw. who is writing drivers in C++? (C++-externals like Gem don't do "random linking" against stdc++ since they require it anyhow)
I don't know what it is that you call «random linkage». either you say "-lstdc++" and it sets the order of "-lstdc++" in the linkage list, or else you don't say it but it appears anyway as "-lstdc++" implicitly because you used "g++" as the compiler name instead of "gcc".
I can tell you that doing ldd on every version of Gem.pd_linux on my computer, new or old, says it is linked to libstdc++.
It is definitely not your usual linkage problem and it evaded several times my logical reasoning about it, because I was making usual suppositions. But the problem is not one of symbol resolution, it's about the initialisation order of a global singleton, where only one version of the initialiser gets run...
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++.
any library written in C++ of course has to link against it. making sure that a binary uses the libstdc++ it was compiled with is totally valid; therefore i have added an explicit linking to Gem that should pull in libstdc++ before anyhting else (like a driver) can pull in a wrong version of it. i consider this a good idea (esp. if it fixes the problem)
fgmasdr IOhannes