Restriction on interface function types

[Iain Buclaw]

On 12 March 2014 18:17, Steve Teale <steve.teale at britseyeview.com> 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.