Resolved: [Haskell-cafe] ffi linking problem
Hello, In case anyone else finds this useful... My linking problem was finally resolved by using the -fvia-C flag when compiling with ghc. Thanks to Stefan O'Rear who pointed out the possibility and wrote:
Does using -fvia-C help at all? The C compiler understands header files and is sometimes better equipped to resolve things.
regards, Jeff
jeff p wrote:
In case anyone else finds this useful...
My linking problem was finally resolved by using the -fvia-C flag when compiling with ghc.
Thanks to Stefan O'Rear who pointed out the possibility and wrote:
Does using -fvia-C help at all? The C compiler understands header files and is sometimes better equipped to resolve things.
If -fvia-C fixes your problem, then your code has a bug, strictly speaking. If your foreign call requires some information from a header file, then the right way to call it is by making a small C wrapper function and calling that. Bear in mind that we'll be deprecating -fvia-C in the future, and also that you might want your code to work in GHCi too, which doesn't read any header files when compiling foreign imports. Cheers, Simon
Hello,
If -fvia-C fixes your problem, then your code has a bug, strictly speaking. If your foreign call requires some information from a header file, then the right way to call it is by making a small C wrapper function and calling that.
I tried to do this but couldn't. I could get GHC to compile and link with warnings of the form: Warning: resolving _my_fun@24 by linking to _my_fun But when I ran the executable, the system crashed at the point that a foreign function was called.
Bear in mind that we'll be deprecating -fvia-C in the future, and also that you might want your code to work in GHCi too, which doesn't read any header files when compiling foreign imports.
I am currently developing on a windows xp machine. After a week of fighting with FFI, I feel forced to conclude that FFI barely works with GHC (and seems to require -fvia-C) and doesn't work at all with GHCi (I think there is an unresolved bug about this). Am I wrong about the state of affairs for windows? thanks, Jeff
On Fri, Jun 01, 2007 at 10:10:53PM -0400, jeff p wrote:
Hello,
If -fvia-C fixes your problem, then your code has a bug, strictly speaking. If your foreign call requires some information from a header file, then the right way to call it is by making a small C wrapper function and calling that.
I tried to do this but couldn't. I could get GHC to compile and link with warnings of the form:
Warning: resolving _my_fun@24 by linking to _my_fun
But when I ran the executable, the system crashed at the point that a foreign function was called.
Bear in mind that we'll be deprecating -fvia-C in the future, and also that you might want your code to work in GHCi too, which doesn't read any header files when compiling foreign imports.
I am currently developing on a windows xp machine. After a week of fighting with FFI, I feel forced to conclude that FFI barely works with GHC (and seems to require -fvia-C) and doesn't work at all with GHCi (I think there is an unresolved bug about this). Am I wrong about the state of affairs for windows?
No, it sounds like you're using the wrong import syntax. That linker warning is a dead givaway you should be using ccall, not stdcall. Stefan
Hello,
No, it sounds like you're using the wrong import syntax.
That linker warning is a dead givaway you should be using ccall, not stdcall.
Ok. I just tried changing this and now things work fairly well. I thought stdcall was the correct syntax for windows. This seems like a strange state of affairs. I have a C library I want to use. I can create an executable which links directly to the library by using stdcall and -fvia-C, but I can't get ghci to use anything which links directly to the library. Or, I can indirectly link to the library via my own C wrapper functions using ccall, no need for -fvia-C, and get either a standalone or a module which ghci will use. thanks for the help, Jeff
On Fri, Jun 01, 2007 at 10:48:12PM -0400, jeff p wrote:
Hello,
No, it sounds like you're using the wrong import syntax.
That linker warning is a dead givaway you should be using ccall, not stdcall.
Ok. I just tried changing this and now things work fairly well. I thought stdcall was the correct syntax for windows.
This seems like a strange state of affairs. I have a C library I want to use. I can create an executable which links directly to the library by using stdcall and -fvia-C, but I can't get ghci to use anything which links directly to the library. Or, I can indirectly link to the library via my own C wrapper functions using ccall, no need for -fvia-C, and get either a standalone or a module which ghci will use.
Actually it makes sense if you know a few of the subtle details. The C compiler, because it parses header files, will not be confused by an incorrect calling convention, in the special case of C. You should not rely on this behavior! ccall refers to the standard C calling convention, on any platform. The Windows API functions use a non-standard calling convention, confusingly named stdcall by Microsoft; GHC only follows established bad terminology. GHCi and -fasm do NOT use the C compiler, and require fully matched signatures. C wrapper functions are not needed to link to external ccall or stdcall library functions. They are only needed for weird calling conventions (like C++) and macros. Attempting to call a ccall function with a stdcall calling sequence, or conversely, will probably cause a crash with modern compilers. It may have worked on very old non-optimizing compilers, but the defaulting thing in your linker should have been removed long ago. Stefan
participants (3)
-
jeff p -
Simon Marlow -
Stefan O'Rear