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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
