[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