www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Function reference accross modules => link error: unresolved external

reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
May 08 2019
next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
May 08 2019
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
May 08 2019
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
May 08 2019