On Sun, 2005-04-17 at 19:22 -0700, Dan Kegel wrote: > But I can't shake the feeling that it's crazy that libaspell > got linked against two different C++ libraries. Can you > try creating a minimal test case demonstrating this > without involving inkscape? If so, maybe it's a glibc > shared library loader bug?
This thread got moved to the libstdc++ list. I have created a minimal test case which also shows a misbind of the std::string + op overload: http://gcc.gnu.org/ml/libstdc++/2005-04/msg00177.html I'm afraid any solution that involves statically linking (or changing) libraries like aspell won't work for me. I need to find a fix that can be deployed in the field. I am currently trying to bring myself up to speed on how all this works, but the C++ ABI is pretty complicated. I'm still trying to figure out exactly what COMDAT sections are, and how template instantiation works at the ELF level. Joe suggested that it seems to be related to this. I thought (but I must be wrong) that COMDAT sections and weak symbols were only put into .o files: once the .o files are combined into the final binary or shared library, the compile time link editor merges the definitions into a local symbol. I also still don't understand why the + op overload is showing up in the symbol table at all. I thought methods defined in headers would just be fancily copy/pasted into wherever they were used. thanks -mike
