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

IOhannes m zmoelnig zmoelnig at iem.at
Thu Oct 15 17:55:13 CEST 2009


Mathieu Bouchard wrote:
> On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
>> Mathieu Bouchard wrote:
>>> Thanks for doing this. I just tried it with
>>> Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb.
>> cool (i guess you not only meant to say that you tried it, but also that
>> the try was successfull)
> 
> Oh. Yes. But I didn't try it with the fglrx libGL. (see below)
> 
>>> It may still fail if any other extern (3DP, OSG, ...) ever links with
>>> libGL before libstdc++, while being loaded before GEM or instead of GEM.
>> yes. as a matter of fact, the ATI-drivers should be fixed.
> 
> In the end, it's not really an ATI-driver bug, because:
> 
>   1. i discovered the bug on my computer that has a non-ATI graphics card,
>      and couldn't get rid of the bug afterwards. I don't know what I did.
>      the Xorg driver is called "intel", not "fglrx". I won't reinstall the
>      OS to see whether I still have the bug that way. The crash is still
>      related to loading libGL in particular in that case.
> 
>   2. the root cause of the bug is always an incompatibility between
>      different versions of gcc. there is no actual bug in the ATI source.
>      there's nothing really wrong with ATI's source and makefiles. it's a
>      GCC bug that propagated in ATI's binaries. Because I have the bug on
>      my computer too, it also propagated into other binaries, it seems.
>      But really, back then, it wasn't a bug yet, because the problem
>      is one of forward-compatibility: the exception-system startup code of
>      gcc 3.x has to support gcc 4.x, but doesn't, because of a change
>      in gcc starting with 4.x...
> 
> that's the info i could get from researching on my computer, web/google,
> and asking some people on IRC, and then putting everything together. but
> i'm not Sherlock Holmes, so it's not elementary to me, and i'm not sure
> i got everything right.

thanks for doing the research.
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)

fgmasrd
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/c6956ed4/attachment.bin>


More information about the Pd-dev mailing list