[Haskell-cafe] Why doesn't text-icu work on 64 bit Windows?

[Yitzchak Gale]

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