[Haskell-cafe] Why doesn't text-icu work on 64 bit Windows?
kyrab at mail.ru
Wed Dec 10 14:12:50 UTC 2014
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
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
>> 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.
More information about the Haskell-Cafe