From: Cyril S. <csc...@de...> - 2005-03-28 00:10:32
|
All, I am installing Gtk2Hs 0.9.7.1 on Windows 2000 as described in http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/. I do not get any error messages when I run Register Gtk2Hs.bat, however trying to run any of the examples from the demo directory with ghci gives me this message: Loading package glib ... can't load .so/.DLL for: HSglib (addDLL: unknown error) I am sure there is no HSglib.dll on my system. There is libHSglib.a, but ghci is looking for a dynamic library. What am I doing wrong? Cheers, Cyril |
From: Duncan C. <dun...@wo...> - 2005-03-28 02:08:43
|
In message <424...@de...> Cyril Schmidt <csc...@de...> writes: > All, > > I am installing Gtk2Hs 0.9.7.1 on Windows 2000 as described in > http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/. > > I do not get any error messages when I run Register Gtk2Hs.bat, however > trying to run any of the examples from the demo directory with ghci gives me > this message: > > Loading package glib ... can't load .so/.DLL for: HSglib (addDLL: > unknown error) > > I am sure there is no HSglib.dll on my system. There is libHSglib.a, but > ghci is looking for a dynamic library. > > What am I doing wrong? You're not doing anything wrong. Sadly we have a problem with GHCi on Windows. Your programs should work just fine if you do an ordinary compile. Because we can't easily get the GHCi versions of the Gtk2Hs libraries working we did not include them in the download. That's why you have no HSglib.o on your system. I should have mentioned this in the release notes. I appologise. I'll go fix it. The reason for the problem goes a bit like this: The Gtk+ .dll files have some slightly odd names. For example while the name of the file that we link to at compile time is say libpango.a, the name of the corresponding dll is libpango-0.dll (or something similar). That's ok for most of the time because the .a file tells the windows system linker the name of the corresponding .dll file. That's why the programs you compile will work, because GHC uses the standard system linker. However GHCi does not work quite that way. It loads everying up itself and so it needs to know the exact name of the dll file to load. It gets the information for which .a & .dll files to load from it's package file (eg glib.pkg, gtk.pkg etc, which is what "Register Gtk2Hs.bat" installs). Unfortunately the GHC package file format assumes that the .a file will have the same name as the .dll file; it uses the same information in the package file for both. So we can get it to work in GHCi by specifying the pango-0 variant or we can get it to work with ordinary GHC by using the other variant. It seems we cannot currently manage both with the same package file. So until we have a good solution we chose to make it work for the stand alone program case rather than the GHCi interactive case. Now on Unix we could create links from one name to the other (this may be possible in Windows if you're using NTFS) but it's a bit of a hack. There are other ways of fixing it that would require changes in GHC. (I should go complain and see if the GHC people have any good ideas). Another hack would be to create duplicate packages that are just for GHCi so while you'd be able to say: $ ghc --make MyGuiProg.hs -o myguiprog.exe to use it in GHCi you'd have to say: $ ghci -package gtk-ghci MyGuiProg.hs I could try hacking this up and see if it can be made to work. If anyone else has any suggestions, please chime in. Duncan |
From: Cyril S. <csc...@de...> - 2005-03-28 20:35:35
|
Duncan, Thank you very much for the explanation. I must admit I do not see any reasonable way to fix it (other than hacking GHCi). Making symbolic links looks like a good idea to me, but I quite agree that it's a hack. Kind regards, Cyril Duncan Coutts wrote: >In message <424...@de...> Cyril Schmidt <csc...@de...> writes: > >>All, >> >>I am installing Gtk2Hs 0.9.7.1 on Windows 2000 as described in >>http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/. >> >>I do not get any error messages when I run Register Gtk2Hs.bat, however >>trying to run any of the examples from the demo directory with ghci gives me >>this message: >> >>Loading package glib ... can't load .so/.DLL for: HSglib (addDLL: >>unknown error) >> >>I am sure there is no HSglib.dll on my system. There is libHSglib.a, but >>ghci is looking for a dynamic library. >> >>What am I doing wrong? >> > >You're not doing anything wrong. Sadly we have a problem with GHCi on Windows. >Your programs should work just fine if you do an ordinary compile. > >Because we can't easily get the GHCi versions of the Gtk2Hs libraries working we >did not include them in the download. That's why you have no HSglib.o on your >system. > >I should have mentioned this in the release notes. I appologise. I'll go fix it. > >The reason for the problem goes a bit like this: >The Gtk+ .dll files have some slightly odd names. For example while the name of >the file that we link to at compile time is say libpango.a, the name of the >corresponding dll is libpango-0.dll (or something similar). That's ok for most >of the time because the .a file tells the windows system linker the name of the >corresponding .dll file. That's why the programs you compile will work, because >GHC uses the standard system linker. However GHCi does not work quite that way. >It loads everying up itself and so it needs to know the exact name of the dll >file to load. It gets the information for which .a & .dll files to load from >it's package file (eg glib.pkg, gtk.pkg etc, which is what "Register Gtk2Hs.bat" >installs). Unfortunately the GHC package file format assumes that the .a file >will have the same name as the .dll file; it uses the same information in the >package file for both. So we can get it to work in GHCi by specifying the >pango-0 variant or we can get it to work with ordinary GHC by using the other >variant. It seems we cannot currently manage both with the same package file. So >until we have a good solution we chose to make it work for the stand alone >program case rather than the GHCi interactive case. > >Now on Unix we could create links from one name to the other (this may be >possible in Windows if you're using NTFS) but it's a bit of a hack. There are >other ways of fixing it that would require changes in GHC. (I should go complain >and see if the GHC people have any good ideas). > >Another hack would be to create duplicate packages that are just for GHCi so >while you'd be able to say: >$ ghc --make MyGuiProg.hs -o myguiprog.exe >to use it in GHCi you'd have to say: >$ ghci -package gtk-ghci MyGuiProg.hs >I could try hacking this up and see if it can be made to work. > >If anyone else has any suggestions, please chime in. > >Duncan > |
From: Duncan C. <dun...@wo...> - 2005-03-29 19:09:01
|
In message <424...@de...> Cyril Schmidt <csc...@de...> writes: > Duncan, > > Thank you very much for the explanation. > > I must admit I do not see any reasonable way to fix it (other than > hacking GHCi). Yes, we should tell the ghc/cabal people now, while cabal is still under development. > Making symbolic links looks like a good idea to me, but I quite agree > that it's a hack. It's even worse than that. :-) Windows has no concept of symbolic links. NTFS supports hard links I believe but MS don't encourage them or make them easy to use. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createhardlink.asp It was a feature they grudingly added to get basic posix compliance so they could get more government contracts. I know many WinXP users use FAT32 in which case hard links are unavaliable. So it's not something that our installer could set up very reliably (and it'd be a pain since the CreateHardLink() functionality is only directly avaliable to compiled programs ie not to batch scripts or MSI installers). Duncan |