I wrote:
1. Some difference in the way ICU builds their DLLs for 64 bit Windows.
kyra wrote:
1. On 64-bit platforms gcc and GHC silently link against Visual C-created import libraries, but resulting exe segfaults. Import libraries should be recreated with native 64-bit dlltool.
Hmm, that would be a pretty complex task, but maybe I'll try it. The question is - if this is the problem, then why do the DLLs generated by Visual Studio work for 32 bits but not 64 bits? I found instructions how to do it here: http://www.willus.com/mingw/colinp/win32/dll/make.html Summary: Create a .def file with this format: EXPORTS Foo Bar where Foo and Bar are the symbols to be exported by the DLL. Then run these commands: gcc -mdll -o junk.tmp -Wl,--base-file,base.tmp bar.o del junk.tmp dlltool --dllname bar.dll --base-file base.tmp --output-exp temp.exp --def bar.def del base.tmp gcc -mdll -o bar.dll bar.o -Wl,temp.exp del temp.exp The first few steps use the .def file to create an .exp file. ICU provides the Visual Studio 2010 .exp files, so I tried just using those. It didn't work. So in order to figure out what symbols to export for each DLL, It looks like I'll need to open the ICU4C projects in Visual Studio 2010. Is this really what you need to go through to compile a basic library from Hackage on 64 bit Windows?
2. Some difference in the FFI bindings that is needed specifically for 64 bit Windows.
2. Perhaps the most important difference between 64-bit Windows and Linux ABIs is that "long" is 4-byte on Windows.
The long C type doesn't seem to be mentioned (at least directly) anywhere in the FFI bindings. Thanks, Yitz