Sometimes a simple thing should be obvious but...

// a.d
module a;

int otherFunc();

main(){
	otherFunc();
}



// myapp.d
import a;
int otherFunc(){
	return(1);
}

Gives me an "unresolved external symbol" for otherFunc() in myapp.d

So, the compiler can see the reference but not the linker. I'm just compiling myapp.d and don't explicitly compile a.d but IMO that shouldn't make any difference.

Any idea what needs to be done?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On 2019-05-08 16:20:22 +0000, Robert M. Münch said:

> Sometimes a simple thing should be obvious but...
> 
> // a.d
> module a;
> 
> int otherFunc();
> 
> main(){
> 	otherFunc();
> }
> 
> 
> 
> // myapp.d
> import a;
> int otherFunc(){
> 	return(1);
> }
> 
> Gives me an "unresolved external symbol" for otherFunc() in myapp.d
> 
> So, the compiler can see the reference but not the linker. I'm just compiling myapp.d and don't explicitly compile a.d but IMO that shouldn't make any difference.
> 
> Any idea what needs to be done?

Correction: I compile the module file too (using DUB).

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Wednesday, 8 May 2019 at 16:20:22 UTC, Robert M. Münch wrote:
> Sometimes a simple thing should be obvious but...
>
> // a.d
> module a;
>
> int otherFunc();
>
> main(){
> 	otherFunc();
> }
>
>
>
> // myapp.d
> import a;
> int otherFunc(){
> 	return(1);
> }

Those are two *entirely different* functions, `a.otherFunc` and `myapp.otherFunc`.

Generally the answer here is "don't do that". Just have module a `import myapp` and then call otherFunc.

But if you must hack around it - and seriously ask yourself if this is good design before committing to it - you can slap `extern(C)` on the `otherFunc` declaraton and definition to force them to match up in the global namespace.

On 2019-05-08 17:02:07 +0000, Adam D. Ruppe said:

> Those are two *entirely different* functions, `a.otherFunc` and `myapp.otherFunc`.

That's what I expected...

> Generally the answer here is "don't do that". Just have module a `import myapp` and then call otherFunc.

That's exactly what I want to avoid because "module a" is a generic one and shouldn't be touched to add any reference to user-specific code. In this case that would be the module name.

> But if you must hack around it - and seriously ask yourself if this is good design before committing to it - you can slap `extern(C)` on the `otherFunc` declaraton and definition to force them to match up in the global namespace.

Thanks, I didn't thought that I need to go the C road for this.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster