Undefined symbols for deferred bindings

[Rouson, Damian]

(This is a resend.  I keep forgetting to turn off HTML formatting)

Janus,

Thanks for the clear explanation.  I¹ll resume testing after Paul¹s patch
lands on the branch.

Damian


On 11/11/09 5:08 AM, "Janus Weil" <janus@gcc.gnu.org> wrote:

> Hi Damian,
> 
>> The code below compiles correctly (hooray!), but the linker can't find the
>> symbols related to the deferred bindings.  It's possible there's a problem
>> in my link line, so you might jump straight to the bottom.  Otherwise, foo
>> defines an abstract type (as in my previous posting); bar extends foo and
>> overrides foo's deferred bindings; and main declares a bar object and passes
>> it to the "rescale" procedure inside foo_module.
> 
> sorry for the late answer. I don't think there's a problem in your
> link line. Rather I would say deffered TBPs are just an unimplemented
> feature for now (if I'm not mistaken). Hopefully that should change
> once Paul's new patch for dynamic dispatch has landed on the branch.
> 
> 
>> Undefined symbols:
>>  "_assign_interface_", referenced from:
>>      ___foo_module_MOD_rescale in foo.o
>>  "_times_interface_", referenced from:
>>      ___foo_module_MOD_rescale in foo.o
>> ld: symbol(s) not found
> 
> Trying to explain these error messages: We had support for ('static')
> TBPs before we had polymorphism. In this old implementation, calling a
> TBP would be translated statically to a call of the bound procedure.
> Since for deferred TBPs, we have nothing that is bound to it, we just
> generate a call to the interface symbol (so that at least the call can
> be checked for correctness etc). But, since this is just an interface,
> not a real procedure, it does not actually exist and linking fails. At
> least that is what I think is happening. Paul or Daniel may be able to
> tell you more about this.
> 
> Cheers,
> Janus
> 
>