On 12 March 2014 18:17, Steve Teale <[email protected]> wrote: > On Wednesday, 12 March 2014 at 14:28:02 UTC, Steven Schveighoffer wrote: >> >> > I saw that, but I think what you encountered was a bug in the >> compiler or differently-generated vtables. I think you should focus on >> trying to identify and fix the bug rather than trying to exploit a >> workaround. >> >> One thing to try is re-compiling all your code. Any changes in vtables >> will mess up the linkage. If the compiler thinks your function to call is in >> index 2 in one compilation, but it's in index 3 in another, bad things will >> happen :) >> > Steve, > > Recompilation has been frequent, and the makefile for the plugin refers to > the sources for the app, and is otherwise just a single source file, so I > don't think it is that. > > My primary suspicion is that I am linking both the plugin and the app using > the static gtkd-2 library. I believe the next step is to link both against a > shared library version of gtkd-2. So far, I've had no success in building > that. If the library code has static module constructors/destructors, or > some such alternative down at the GTK+3 OOP C level, that uses a distinct > text or data segment or something, then I can understand that I might well > be hosed. > > It's also noteworthy that I can't use an interface as a 'base class' for the > plugin, even though the system should work with quite a limited set of > methods. That works to the extent that methods that don't access data work > OK, but if they do, the edifice comes tumbling down. > > I'll have to brush up my command-line GDB skills to get much further - > something I'm not looking forward to. Last time I did it was pre Iain > Bucklaw when I was trying to sort out crashes in GDC. >
My GDB work is yet to be fully released into the wild, but it's looking as a good solid base from where I'm testing.
