Gtk2Hs

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Fri Mar 4 14:54:37 EST 2005


On Fri, 2005-03-04 at 19:20 +0000, David Owen wrote:
> Hi all,
> 
> I have recently downloaded and installed Gtk2Hs but am having problems 
> running the sample programs.
> 
> I am most interested in getting the TestEmbedMoz program working.  However 
> when I try to compile it (either using make or ghc on the command line) it 
> says that the interface file for MozEmbed does not exist (cannot find 
> interface file for Graphics.UI.Gtk.MozEmbed).  I have tried it using both 
> 2.4 and 2.6 of the Windows versions of Gtk+ and the corresponding Gtk2Hs 
> packages and neither seem to provide the file.  I have also built the 
> packages from source and tried to compile but to no avail.  Maybe I need to 
> do something wlse with the MozEmbed package file (?).  Mozilla 1.4 or 
> greater is installed as needed.

We do not currently build the MozEmbed package on Windows though it
might be possible to do so. 

In fact, I just checked and it is not at all clear that GtkMozEmbed
compiles on Win32 in any released version of Mozilla. See this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=256560

And:
http://severna.homeip.net/gtkmozwin32.php

It looks like at the moment you'd have to compile mozilla from source.
Some people seem to have be working on it and it might make it into
mozilla 1.8.

> My second problem is running other test programs that have successfully 
> compiled.  For example the ButtonBox when I run it gives an "Entry Point Not 
> Found" error, details: "The procedure entry point 
> libiconv_set_relocation_prefix could not be located in the dynamic link 
> library iconv.dll".  I've tried reinstalling Gtk+ and GtkHs a few times but 
> it hasn't helped.

My first guess is that you have another version of iconv.dll on your
PATH that is being picked up but it is an older version or something.

Try searching your whole disk for "iconv.dll".

BTW which version of Gtk+ did you install exactly? which _rc number?

--

Are there any Win32 experts on these lists who know if there is a more
reliable way of matching up dlls to programs so that they always get the
right versions?

If one is distributing a single application you can stick the dlls into
the same directory as the .exe but obviously for a Haskell library our
users will be putting .exe files in any old directory and expecting them
to work.

Duncan



More information about the Libraries mailing list