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

IOhannes m zmoelnig zmoelnig at iem.at
Thu Oct 15 19:15:23 CEST 2009


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20091015/77dc306c/attachment.bin>


More information about the Pd-dev mailing list