building HSQL MySQL on windows (Was: FFI imported function names)

Ok, enough talking to myself :)
If anybody ever wants to build hsql-mysql on windows and has the same
problems as I had, here's how it should be done.
The problem I had seemed to be that libmysql.dll uses stdcall, but
names its functions without @<n> decoration. Thus, when linking a
Haskell program against it, names with @<n> cannot be resolved.
The solution is pretty much a hack. Somebody from the Ruby community
used to run into the same problem, from the same situation -- namely
building ruby mysql bindings.
Here is the procedure one person suggests
http://rubydotnetproxy.rubyforge.org/mysql_win.html
It worked perfectly for me. Of course, with some cabal specifics,
which is obviously not described in the above page.
The solution was to create a def file listing the names which could
not be resolved and creating a .a file based on the dll and this def
file.
2008/12/24 Daniil Elovkov
Mm, actually I didn't change the calling convention ffi imports when I thought I did. I tried to do it through defines...
Well, by explicitly saying ccall I get the names without @<n> decoration. And it all links well. But I get segault when I run the code, which should mean that calling conventions didn't match.
Actually I found some ramblings on the internet that there's something wrong with libmysql.dll and libmysql.lib in this respect, but they were from 2004.
Thus the question: how do I link against a lib file in ghc? When I say -lmysql on command line it strictly searches for dll and complains if it's not found. Adding lib exlpicitly on the cmd line doesn't seem to have any effect.
Thanks
2008/12/24 Daniil Elovkov
: Hello
How is decided whether the name of imported function gets the ending of the form @4 in ghc?
I'm having this problem on Windows trying to use HSQL MySQL on windows.
I compile HSQL Oracle backend and I get names without that. It's ok. With HSQL MySQL I get names with that stuff. It prevents me from further linking to dll. Supplying in the ghc command-line the "lib" file where names have those marks doesn't have any effect.
The linker says that fname@NN cannot be resolved.
Can I control that?
The ffi calling convention doesn't (and shouldn't as I understand) affect this. The only difference is that in the case of mysql the header file itself where functions are described marks it STDCALL. Is that the reason?
Also I changed ffi import line from "hsmysql.h func" to just "func", to no avail.
ghc 6.8.2
I'm lost. Please help.
-- Daniil Elovkov
-- Daniil Elovkov
-- Daniil Elovkov

Daniil Elovkov wrote:
Ok, enough talking to myself :)
If anybody ever wants to build hsql-mysql on windows and has the same problems as I had, here's how it should be done.
The problem I had seemed to be that libmysql.dll uses stdcall, but names its functions without @<n> decoration. Thus, when linking a Haskell program against it, names with @<n> cannot be resolved.
The solution is pretty much a hack. Somebody from the Ruby community used to run into the same problem, from the same situation -- namely building ruby mysql bindings.
Here is the procedure one person suggests http://rubydotnetproxy.rubyforge.org/mysql_win.html
It worked perfectly for me. Of course, with some cabal specifics, which is obviously not described in the above page.
The solution was to create a def file listing the names which could not be resolved and creating a .a file based on the dll and this def file.
GHC adds the @N suffix to any foreign function declared with the stdcall calling convention, which I think matches what gcc does. I wonder how it works for C. Cheers, Simon
2008/12/24 Daniil Elovkov
: Mm, actually I didn't change the calling convention ffi imports when I thought I did. I tried to do it through defines...
Well, by explicitly saying ccall I get the names without @<n> decoration. And it all links well. But I get segault when I run the code, which should mean that calling conventions didn't match.
Actually I found some ramblings on the internet that there's something wrong with libmysql.dll and libmysql.lib in this respect, but they were from 2004.
Thus the question: how do I link against a lib file in ghc? When I say -lmysql on command line it strictly searches for dll and complains if it's not found. Adding lib exlpicitly on the cmd line doesn't seem to have any effect.
Thanks
2008/12/24 Daniil Elovkov
: Hello
How is decided whether the name of imported function gets the ending of the form @4 in ghc?
I'm having this problem on Windows trying to use HSQL MySQL on windows.
I compile HSQL Oracle backend and I get names without that. It's ok. With HSQL MySQL I get names with that stuff. It prevents me from further linking to dll. Supplying in the ghc command-line the "lib" file where names have those marks doesn't have any effect.
The linker says that fname@NN cannot be resolved.
Can I control that?
The ffi calling convention doesn't (and shouldn't as I understand) affect this. The only difference is that in the case of mysql the header file itself where functions are described marks it STDCALL. Is that the reason?
Also I changed ffi import line from "hsmysql.h func" to just "func", to no avail.
ghc 6.8.2
I'm lost. Please help.
-- Daniil Elovkov
-- Daniil Elovkov
participants (2)
-
Daniil Elovkov
-
Simon Marlow