extern (C) private linking issue

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Mon Feb 26 00:31:25 PST 2007


Derek Parnell wrote:
> On Sun, 25 Feb 2007 23:33:25 -0500, William R. DeVore wrote:
> 
>> I am running into an issue under windows during linking.
>>
>> I am getting an optlink error based on a private function in a module:
>>
[snip]
>>
>> Linux linker respects the scope but window doesn't. I am using dmd 1.007
>>
>> Any suggestions? Should I submit a bugzilla?
>> I really don't want to have a unique name for each collision callback function inside a module if I can avoid it.
> 
> I'll have a go at this one, but I'm just guessing...
> 
> The 'private' qualifier does "hide" is from the compiler's point of view.
> But it is not so much "hiding" as "preventing access". That is, the
> compiler will stop code in one module from trying to call a private
> function in another module.

Pretty good guess ;).

> The "extern (C)" qualifier stops the compiler from mangling the name.
> Without this qualifier, the compiler adds the module name, and the argument
> signature to the name of a function in the object file. That means that two
> functions with the same name, but in different modules get different
> linkage names. However, by using "extern (C)" you override that so that
> each module's object file will contain the same linkage name. 
> 
> Why do you need to specify "extern (C)"?

Seeing the word "callback" so often makes me think he probably uses 
these functions for use as a callback (function pointer) passed to a C 
API. So he needs them to use the C calling convention, which they will 
use when declared extern(C).
I have also on occasion wanted to specify calling convention without 
specifying mangling, but current D doesn't offer that possibility :(.



More information about the Digitalmars-d mailing list