FLI "trying to call to unresolved external function"

Hi there,

I have been trying to link some foreign C code, to no avail so far. The  
problem could be some simple configuration, probably, I do not have much  
experience using FLI. I apologize if it is something straight-forward that  
everyone knows.

It seems that Lispworks 6.1.1 cannot resolve to foreign function in a  
supplied dll. I thought it could have to do with my C code so tried to  
generate a sample DLL in VC++ Express 2010 without changing anything to  
see if that works but it doesn't.

One of the sample functions looks like this:

__declspec(dllexport) int fnmiles(void)
{
	return 42;
}

My lisp FLI definition looks like this:

(fli:define-foreign-function
     (fnmiles "fnmiles" :source) nil
   :result-type :int
   :language :ansi-c)

the module registers via fli:register-module seemingly no problem. When I  
try to run the function, I get this error:

CL-USER 5 > (fnmiles)

Error: Foreign function FNMILES trying to call to unresolved external  
function "fnmiles".

I am not sure what the problem is. One of the suspicions that I had is  
that the code generated by the Visual C++ is not ansi-c compliant even  
though I do not use any C++ specific code, however that is pretty much how  
far my guesses go for me. I tried creating dlls using example code from  
the Internet using gnuc but had exact the same problem.

If someone would have a simple example of C code that links to Lispworks  
that would be awesome.

Thanks,
	Yuri

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: FLI "trying to call to unresolved external function"

Hi Yuri,

I would suggest you check the calling convention (stdcall or cdecl) used to link your DLL and use the same convention in the FLI definition.

See http://cl-cookbook.sourceforge.net/win32.html

Cam

On 24 mars 2013, at 14:55, "Yuri Davidovsky" <yury.davidouski2@mail.dcu.ie> wrote:

Hi there,

I have been trying to link some foreign C code, to no avail so far. The problem could be some simple configuration, probably, I do not have much experience using FLI. I apologize if it is something straight-forward that everyone knows.

It seems that Lispworks 6.1.1 cannot resolve to foreign function in a supplied dll. I thought it could have to do with my C code so tried to generate a sample DLL in VC++ Express 2010 without changing anything to see if that works but it doesn't.

One of the sample functions looks like this:

__declspec(dllexport) int fnmiles(void)
{
return 42;
}

My lisp FLI definition looks like this:

(fli:define-foreign-function
(fnmiles "fnmiles" :source) nil
:result-type :int
:language :ansi-c)

the module registers via fli:register-module seemingly no problem. When I try to run the function, I get this error:

CL-USER 5 > (fnmiles)

Error: Foreign function FNMILES trying to call to unresolved external function "fnmiles".

I am not sure what the problem is. One of the suspicions that I had is that the code generated by the Visual C++ is not ansi-c compliant even though I do not use any C++ specific code, however that is pretty much how far my guesses go for me. I tried creating dlls using example code from the Internet using gnuc but had exact the same problem.

If someone would have a simple example of C code that links to Lispworks that would be awesome.

Thanks,
Yuri

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: FLI "trying to call to unresolved external function"

C++ does name-mangling.

http://en.wikipedia.org/wiki/Name_mangling .

Wrap your C code in an 'extern "C" { ... }" directive and see if that helps.

I don't remember if simply using a .C extension instead of .CPP will 
solve the problem ...

[Then, your next problem will be to figure out the correct calling 
convention.  Windows system calls use the Pascal calling convention 
(first arg pushed first), whereas C programs use the C calling 
convention (first arg pushed last).]

pt


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: FLI "trying to call to unresolved external function"

If using Visual Studio projects you'll want to specify the 'Compile as C' as part of the C/C++ settings under 'Advanced'. In that case you won't need the extern C since it will be C.. This is of course assuming you're not actually doing C++. This corresponds to the command line option /TC (as opposed to C++ which is /TP)..

Personally if I create stuff through visual studio I'll make a blank project template and then alter settings as needed.. typically easier to build up from blank than it is to use a template and remove silly things like precompiled headers and extraneous files that it'll auto-generate for you.

On Sun, Mar 24, 2013 at 12:29 PM, Yuri Davidovsky <yury.davidouski2@mail.dcu.ie> wrote:

Hi Paul,

your advice to wrap the code into extern "C" seems to have helped, thanks. The C function produces the expected result within lisp now.

However, for those who will be threading this path, to make it work I had to remove the automatically created function templates from the project header files created by VC++, otherwise the compiler did not want to take the extern declaration.

On Sun, 24 Mar 2013 16:11:16 -0000, Paul Tarvydas <paultarvydas@gmail.com> wrote:

C++ does name-mangling.

http://en.wikipedia.org/wiki/Name_mangling .

Wrap your C code in an 'extern "C" { ... }" directive and see if that helps.

I don't remember if simply using a .C extension instead of .CPP will solve the problem ...

[Then, your next problem will be to figure out the correct calling convention. Windows system calls use the Pascal calling convention (first arg pushed first), whereas C programs use the C calling convention (first arg pushed last).]

pt

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html