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...
Yes, it is ultimately GCC's fault, but they won't fix it because they
can't fix it because it's just too late and they can't do anything about
it now that wouldn't make the problem more complicated, and then they
wouldn't be able to propagate the fix because the problem has been bundled
with a zillion linux distros before anyone realised that it was gonna be a
problem (?).
I know you are referring to the usual idea that something called a
"driver" wouldn't be written in C++, but not only those driver-writers
don't care about all the tradition and peer-pressure against writing
"drivers" in C++, but also, those drivers have nothing to do with the
Linux kernel, so it's pretty much outside of that culture. Afaik those
video drivers are made of one-half XFree-format drivers, and one-half
ELF-SO format drivers, so, it's 100% userspace.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
