I finally made it to install Haskell SDL bindings on Windows. Using this:
> $env:Path += ";C:\SDL;C:\SDL\bin;C:\SDL\include;C:\SDL\lib"
> cabal install SDL --extra-include-dirs="C:\SDL\include" --extra-lib-dirs="C:\SDL\lib"
This works, as long as Cygwin is installed for the configure script. However, I wrote a tiny test script:
import Graphics.UI.SDL as SDL
import Control.Monad (void)
import Control.Exception (bracket_)
main = bracket_ (SDL.init [InitEverything]) quit $ do
screen <- setVideoMode 800 600 0 []
SDL.flip screen
void $ waitEvent
Trying this now gives me this error message:
*Main> :main
Loading package SDL-0.6.4 ... <interactive>: mingw32: Cannot find specified module.
can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL)
Now I was looking for that mingw32.dll but I couldn't find it on my computer, though I have MinGW32 installed. Does anyone have had any experience here?
Using SDL-0.6.4, GHC 7.4.2 from Haskell Platform 2012.4.0.0. Windows 7 64-Bit.
ADDITION: I have now also tried it in the way A Haskell Adventure In Windows recommends, and that has the very same result.
It may be a 64 vs. 32 bit issue. Try copying that .dll to:
64-bit version of Windows: copy to c:\windows\syswow64
32-bit version of Windows: copy to c:\windows\system32
That helped me with FTGL - see here
I used MSYS/MinGW to build, and I was having the exact same problem. After fiddling around I found that the flag -lmingw32 (in the file sdl-config) is being used, and this seems to imply mingw32.dll. I simple remove this flagged, and everything worked.
Related
I have the following gloss program:
module Easy where
import Graphics.Gloss
main :: IO ()
main = display (InWindow "My Window" (200,200) (10,10)) white (Circle 80)
However when I run stack runghc Easy I get the following error:
Easy: user error (unknown GLUT entry glutInit)
I tried copying freeglut/bin/(platform)/freeglut.dll to C:\Windows\System32 and renaming it to glut32.dll but the error remains. Can anyone help?
From this thread:
I got GLUT to install! I'd been using the 32-bit version of the DLL,
but I switched to the 64-bit version and got it to build. For the
record, I downloaded this:
http://files.transmissionzero.co.uk/software/development/GLUT/freeglut-MinGW.zip
I unzipped it to D:\Projects\libs, which is where I have my
third-party libraries, so there's now a D:\Projects\libs\freeglut
directory with include, lib, and bin subdirectories. The 64-bit DLL is
in an x64 subdirectory in bin.
Next, I made a copy of D:\Projects\libs\freeglut\bin\x64\freeglut.dll
in the same directory, naming it glut32.dll.
Unfortunately, I'm not getting a simple example program from this open gl tutorial to work.
ghc --make gfx.hs
Could not find module ‘Graphics.UI.GLUT’
[..]
Then I tried the following:
cabal install GLUT
Warning: The package list for 'hackage.haskell.org' is 44.1 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Configuring OpenGLRaw-3.2.2.0...
Failed to install OpenGLRaw-3.2.2.0
Build log ( /home/m/.cabal/logs/OpenGLRaw-3.2.2.0.log ):
Configuring OpenGLRaw-3.2.2.0...
setup-Simple-Cabal-1.22.5.0-x86_64-linux-ghc-7.10.3: Missing dependency on a
foreign library:
* Missing C library: GL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Error: some packages failed to install:
GLURaw-2.0.0.2 depends on OpenGLRaw-3.2.2.0 which failed to install.
GLUT-2.7.0.10 depends on OpenGLRaw-3.2.2.0 which failed to install.
OpenGL-3.0.1.0 depends on OpenGLRaw-3.2.2.0 which failed to install.
OpenGLRaw-3.2.2.0 failed during the configure step. The exception was:
ExitFailure 1
It looks like the missing C library is the problem. I'm using nixOS, does anybody know which steps I'd have to do in order to get this running?
If you want to use nix-shell:
$ nix-shell -p 'haskellPackages.ghcWithPackages (p: [ p.GLUT ])'
will give you a shell with ghc that know GLUT
I've try with this code (from the wiki page you mentioned)
import Graphics.UI.GLUT
main :: IO ()
main = do
(_progName, _args) <- getArgsAndInitialize
_window <- createWindow "Hello World"
displayCallback $= display
mainLoop
display :: DisplayCallback
display = do
clear [ ColorBuffer ]
flush
But the more preferable way is to create shell.nix so you don't need to remember it. To use shell.nix, just call nix-shell without argument in the directory where it is or nix-shell /path/to/shell.nix anywhere.
shell.nix adopted from the manual
{ nixpkgs ? import <nixpkgs> {} }:
with nixpkgs;
let
ghc = haskellPackages.ghcWithPackages (ps: with ps; [
GLUT
]);
in
stdenv.mkDerivation {
name = "my-haskell-env";
buildInputs = [ ghc ];
shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";
}
For a bigger project you might want to use cabal or stack but I think that would be another story.
In nixos, libraries aren't usually available on the path where cabal expects them to be. Try the following:
nix-shell -p libGL libGLU freeglut
cabal install GLUT
On Linux (Nix is a Linux distribution) the LSB specifies that libGL is part of the desktop profile. That means having at least the X11 client libraries installed. libGL is a bit special though and is permitted to be overridden by the graphics driver installation.
What this boils down to is: Install the graphics drivers for your GPU. If you're using an Intel or a AMD GPU install the Mesa drivers. If your system has a NVidia GPU I recommend the proprietary NVidia drivers.
I installed the SourceGraph package using cabal:
cabal install SourceGraph
It was installed perfectly without any errors.
Now, I've created a file called Test.hs to test if I am able to import this package and use it. These are the contents of Test.hs:
module Test where
import SourceGraph
main = putStrLn "Hello World!"
When I do ghc Test I get the following error:
Could not find the module 'SourceGraph'
When I do ghc-pkg list I cannot find SourceGraph in the list, though all dependencies installed along with it are visible.
I checked in C:\Users\MyName\AppData\Roaming\cabal\packages\hackage.haskell.org and I can see the SourceGraph folder there.
But there is no .conf file for SourceGraph in C:\Users\MyName\AppData\Roaming\ghc\x86_64-mingw32-7.10.2\package.conf.d.
Also, all the .log files in C:\Users\MyName\AppData\Roaming\cabal\logs have a line In-place registering packagename-version... at the end, but SourceGraph-0.7.0.7,log doesn't.
Help please?
[System Specifications: GHCi version 7.10.2, Cabal Version: 1.22.4.0, OS: Windows 8 Pro, Processor: Intel Core i5 (64 bit)]
SourceGraph is not a library, it is a program to be run on the command line.
See it's hackage page
There it says (with added $s for the bash prompt):
To use SourceGraph, call it as either:
$ SourceGraph path/to/Foo.cabal
Or, if your project doesn't use Cabal, then there is limited support for > using an overall module from your program/library:
$ SourceGraph path/to/Foo.hs
I tried to install system-fileio to my global package db and failure was :
c:\Haskell\2013.2.0.0\bin>cabal-1.20.0.1.exe install system-fileio
Resolving dependencies...
Configuring system-fileio-0.3.13...
Building system-fileio-0.3.13...
Failed to install system-fileio-0.3.13
Last 10 lines of the build log ( C:\Users\bitli\AppData\Roaming\cabal\logs\system- fileio-0.3.13.log ):
The import of `System.IO.Error' is redundant
except perhaps to import instances from `System.IO.Error'
To import instances alone, use: import System.IO.Error()
lib\hssystemfileio-win32.c: In function 'hssystemfileio_copy_permissions':
lib\hssystemfileio-win32.c:10:17:
error: storage size of 'st' isn't known
lib\hssystemfileio-win32.c:11:2:
warning: implicit declaration of function '_wstat64'
cabal-1.20.0.1.exe: Error: some packages failed to install:
system-fileio-0.3.13 failed during the building phase. The exception was:
ExitFailure 1
I tried it on Windows 7.
I just ran into this same problem on Windows 7 with system-fileio-0.3.13, using both the windows command line with Haskell Platform 2013.2.0.0's built-in mingw and also inside msys with a newer mingw64. The problem appears to be caused by a change introduced between system-fileio-0.3.12 and system-fileio-0.3.13. system-fileio's git repo doesn't seem to have a web interface to link to, but 0.3.12's lib\hssystemfileio-win32.c uses:
struct _stat st;
int rc = _wstat(old_path, &st);
while 0.3.13's hssystemfileio-win32.c has changed to:
struct _stat64 st;
int rc = _wstat64(old_path, &st);
Copying 0.3.12's hssystemfileio-win32.c over top of 0.3.13's does seem to allow it to build, though I don't know if it actually functions correctly.
I don't know if this will work for you, but I'm trying to build yesod on Windows 7 (inside a sandbox with an upgraded cabal-install from the one in the Haskell Platform) and I extracted a system-fileio 0.3.13 tarball from Hackage, copied 0.3.12's hssystemfileio-win32.c over, and then did a cabal sandbox add-source ../system-fileio-0.3.13 inside my yesod sandbox. My cabal install of yesod could then proceed and seems to have worked. If you're doing a system install of system-fileio, you probably should be able to just build in the extracted and modified system-fileio-0.3.13 directory directly.
I'm sure someone who knows something about Haskell and cabal will be able to provide a proper solution instead of this hack.
I am using ghc 7.6.3. I installed wxHaskell from here: https://github.com/wxHaskell/wxHaskell
It worked, the sample programs compile and the run successfully.
The only problem now is that I want to distribute a wxHaskell application on mac OS X. I tried using macosx-app and cabal-macosx (https://github.com/michaelt/cabal-macosx) to make an "app" file. It runs fine on my machine, but it fails to run on another computer. I get the following error:
Dyld Error Message: Library not loaded: /Users/user/.cabal/lib/wxc-0.90.1.0/ghc-7.6.3/libwxc.dylib.
I am using OS X 10.8.4 (Mountain Lion), but I would be also interested in compiling apps on Windows and redistribute them too.
What would be the best way to redistribute wxHaskell apps?
Setup.hs
-- Example Setup.hs for the wxHello app.
import Distribution.MacOSX
import Distribution.Simple
main :: IO ()
main = defaultMainWithHooks $ simpleUserHooks {
postBuild = appBundleBuildHook guiApps -- no-op if not MacOS X
}
guiApps :: [MacApp]
guiApps = [MacApp "WxHello"
(Just "resources/WxHello.icns")
Nothing -- Build a default Info.plist for the icon.
[] -- No other resources.
[] -- No other binaries.
ChaseWithDefaults -- Try changing to ChaseWithDefaults
]
wxHello.cabal:
Name: wxHello
Version: 0.1.0
Stability: Alpha
Synopsis: wxWidgets `Hello World' example for cabal-macosx
Description:
Example showing how to use cabal-macosx to build an application
bundle for a simple `Hello World' program using the wxWidgets GUI
toolkit.
Category: Data
License: BSD3
License-file: LICENSE
Copyright: Andy Gimblett <haskell#gimbo.org.uk>
Author: Andy Gimblett <haskell#gimbo.org.uk>
Maintainer: Andy Gimblett <haskell#gimbo.org.uk>
Build-Type: Custom
Cabal-Version: >=1.6
Executable WxHello
hs-source-dirs: src
Main-is: Main.hs
Build-Depends: base >= 3 && < 5, cabal-macosx, wx
ghc-options: -fwarn-tabs -threaded -Wall
Here are the dylib files inside the generated package:
WxHello.app $ find . | grep dylib
./Contents/Frameworks/Users/user/.cabal/lib/wxc-0.90.1.0/ghc-7.6.3/libwxc.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu_net-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu_xml-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_adv-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_aui-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_core-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_gl-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_html-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_propgrid-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_qa-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_ribbon-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_richtext-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_stc-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_webview-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_xrc-2.9.5.0.0.dylib
./Contents/Frameworks/usr/lib/libc++abi.dylib
./Contents/Frameworks/usr/lib/libexpat.1.dylib
./Contents/Frameworks/usr/lib/libiconv.2.dylib
./Contents/Frameworks/usr/lib/libstdc++.6.dylib
./Contents/Frameworks/usr/lib/libz.1.dylib
The last redistributable I made in Windows with wxHaskell needed the files
mingwm10.dll and
wxmws28u_gcc.dll
to be in the same folder as the .exe (not just somewhere on my path).
This was using a previous version of wxHaskell, which compiled against a previous version of wxWidgits itself, so presumably you'd need the wx dll to have 29 in it rather than 28.
I compiled with static linking too:
ghc -static -optl-static -optl-mwindows Main -o Project.exe
the -optl-mwindows gets rid of the command prompt window which would otherwise appear alongside your app.
It might be helpful to include your .cabal and Setup.hs files.
From the documentation on cabal-macosx, it seems that you need to ensure that your MacApp data value in Setup.hs gets the appropriate mode for ChaseDeps (use ChaseWithDefaults instead of DoNotChase) in order to build redistributable app bundles.
If you have done that but still get the same error, I would check inside the resulting app bundle to see if the necessary libraries got copied in there at all. You may find enough information to file a bug with the cabal-macosx maintainer.
Edit
Based on what you've included, the setup looks correct, and it appears to have at least copied the library dependencies in. I think the problem is probably with the cabal-macosx package.
Looking at the source code to the dependency-fixup code, it looks like it should have printed a bunch of "Updating <library>'s dependence on <path> to <path>" lines as it was building the bundle. Did you see those? Were there any lines updating the binary itself?
I am not very experienced with the OS X linking process, but I would think that unless the binary is linked after copying the libraries, it would need to be updated as well. You should be able to use /usr/bin/otool -L <filename> and /usr/bin/install_name_tool to manually fix up the paths in binaries the install process may have missed.
Here are the man pages for those two tools:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/install_name_tool.1.html
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/otool.1.html