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

[kyra]

On 10-Dec-14 15:56, Yitzchak Gale wrote:
>> No, no. If you have existing .def file the single thing to do is 'dlltool -l
>> <import library name> -D <dll file name> -d <.def filename>'.
> I tried that - there was no output.
> Note that in dlltool --help it says that -D is for *input* DLL file.
I did this multiple times with success :) I think there is something 
wrong with your .def file, perhaps.

In this use case dlltool needs *no* DLL itself -- only its name. For 
some reasons dlltool ignores a clause of 'LIBRARY' statement in .def 
file and uses whatever name you supply to -D option.

For example, to generate import library for icuin52.dll you can use the 
following command-line:
dlltool -l libicudt.a -D icuin52.dll -d icuin52.def
where icuin52.def is the single input *file*, others arguments are 
parameters only, you need no have physically present icuin52.dll at all.

>> The problem is how to obtain .def file from existing dll…
>> 1. Use Microsoft 'dumpbin' utility, which gives a list of exported symbols
>> when run with '/EXPORTS' flag. The utility should be available from VS
>> community edition at least.
> I have full VS 10, so I have dumpbin. But the exports list it
> creates has many C++ mangled symbols, like:
>
> ??0?$EnumSet at W4UDateFormatBooleanAttribute@@$0A@$03 at icu_54@@QEAA at AEBV01@@Z
>
> When I try to create a .exp using dlltool with a .def containing
> junk like that, it fails:
>
> dqsfc.s: Assembler messages:
> dqsfc.s:4102: Error: bad expression
> dqsfc.s:4102: Fatal error: rva without symbol
> dlltool: as exited with status 1
These are mangled Visual C++ names, you can't use them at all and you 
don't need them at all, you should simply remove all of them from your 
.def file.

>> 2. Try to link to DLLs *directly* -- using binutils' facility to link
>> against DLL directly instead of it's import lib.
> That would be much better. If we can get that to work,
> we can teach cabal how to do it too. Then FFI will work
> again on Windows 64 bits. The problem is that binutils
> does not understand DLLs from VS on 64 bits, it seems.
I successfully used several Windows 64 Visual C++- generated DLLs 
through FFI. Usually there are no problems with them if your generate 
import libraries as described above.

Cheers,
Kyra