Installing SDL on Windows for Haskell (GHC) - haskell

Background:
I've been using the gloss library for some simple diagram work. But when it came time for something more interactive, I found I wanted a more powerful library. After doing some research, I decided that I liked the features of the SDL library and wanted to try to install the Haskell bindings for it. I have to this point been unsuccessful.
Part 1:
How do I install and configure the SDL binaries so that they can be used by the Haskell bindings?
Part 2:
Which one of the numerous and ill documented SDL packages on Hackage it the current preferred binding in the community? How do I get that package to install correctly?
Part 3: (Optional)
If SDL is not a good fit for haskell development what is the preferred alternative?

I am going to answer your question for SDL2 (should also work for SDL1 with some modifications).
Install pkg-config for Windows
(How to install pkg config in windows?)
This tool is very important. It is used by various Cabal packages to search for libraries and contains directions for linking and compiling.
Download the SDL development libraries for Windows/MinGW:
http://libsdl.org/release/SDL2-devel-2.0.3-mingw.tar.gz
If you have installed the 32-bit version of the Haskell platform, extract the folder i686-w64-mingw32
For 64-bit versions extract x86_64-w64-mingw32
You will get following layout:
include
share
bin
lib
"Register" the library with pkg-config.
Either copy lib/pkgconfig/sdl2.pc into the folder of your pkg-config.exe or modify/create the PKG_CONFIG_PATH accordingly. Check that you set up everything correctly:
C:\pkg-config --list-all | grep sdl2
sdl2 sdl2 - Simple DirectMedia Layer is a cross-platform multimedia
library designed to provide low level access to audio, keyboard,
mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
Add the bin folder to your PATH environment variable.
Install the sdl2 package via the Cabal installer and tell Cabal where to find your libraries.
Example:
cabal install sdl2 --extra-include-dirs=C:\lib\sdl2\include --extra-lib-dirs=C:\lib\sdl2\lib\
To test my installation, I have written a small example:
https://github.com/ftl2014/haskell-stuff/blob/master/sdl/
Caveat emptor:
If Cabal complains about a "missing" library, it might be the case that library was actually found but it is incompatible (e.g. using a 32-bit instead of a 64-bit version) or corrupt. The same is true for header files.
For some reason, Cabal complained about not finding SDL.h, and I had to use the headers in the root include folder of the archive (but maybe I was just drinking too much Kool-aid).

I wasn't able to get it to install on my system. Here's what I tried. Strangely, I was able to get configure find the header files but not the actual binary.
Let's try it. I have installed the new 2014 Haskell Platform.
cabal install sdl
Configuring SDL-0.6.5...
setup.exe: The package has a './configure' script. This requires a Unix
compatibility toolchain such as MinGW+MSYS or Cygwin.
Failed to install SDL-0.6.5
GHC in the Haskell Platform comes with MinGW, so we probably need to install MSYS. The MSYS page says to install minggw get, which says to install
An automated GUI installer assistant called mingw-get-setup.exe is the preferred method for first time installation. This will guide you through the setup of the mingw-get installer proper; you will then use this to perform further package installations, and to manage your installation.
Running the installer with the default options gives us the following screen:
We already have mingw from installing the Haskell platform, so we'll click on only the last item in the list, msys-base, and select "Mark for Installation". Then, in the "Installation" menu in the top left, select "Apply Changes". This asks if it is ok to proceed, and we select "Apply"
This installer didn't put msys-base in the path, we can add it to the path, and try installing sdl again
set PATH=C:\MinGW\msys\1.0\bin\;%PATH%
cabal install sdl
Configuring SDL-0.6.5...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for sdl-config... no
checking for sdl11-config... no
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5
We need to download and install libsdl. I went to the libsdl download page and downloaded the Win32 development libraries, SDL-devel-1.2.15-mingw32.tar.gz. I extracted this archive (7-zip can extract both tar archives and gzip compressed files). For convenience, I moved the SDL-1.2.15 directory to c:. We'll add this to the path, as suggested by the previous error, and try again
set PATH=C:\SDL-1.2.15\bin\;%PATH%
cabal install sdl
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
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.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
We can make part of this error go away by adding the suggested --extra-include-dirs flag, but still get the following error
cabal install sdl --extra-include-dirs=c:\SDL-1.2.15\include
* Missing C library: SDL
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.
Adding the --extra-lib-dirs flag with c:\SDL-1.2.15\bin or C:\SDL-1.2.15\lib or c:\SDL-1.2.15 failed to fix this problem.

Related

Cabal can't find foreign libraries

Recently I was trying to install llvm-general-3.5.1.0 package.. for about a week. Basically I am getting this error: link. My situation is identical. Windows 10, ghc 7.10.2, cabal 1.22.4.0. I installed llvm 3.5.2 from sources with cmake and everything went fine. In llvm/lib directory I have *.lib files (eg. LLVMAnalysis.lib).
But somehow cabal can't see those libraries and gives this frustrating error:
Configuring llvm-general-3.5.1.0...
setup.exe: Missing dependencies on foreign libraries:
* Missing C libraries: LLVMLTO, LLVMObjCARCOpts, LLVMLinker, LLVMipo,
LLVMVectorize, LLVMBitWriter, LLVMCppBackendCodeGen, LLVMCppBackendInfo,
LLVMTableGen, LLVMDebugInfo, LLVMOption, LLVMX86Disassembler,
LLVMX86AsmParser, LLVMX86CodeGen, LLVMSelectionDAG, LLVMAsmPrinter,
LLVMX86Desc, LLVMX86Info, LLVMX86AsmPrinter, LLVMX86Utils, LLVMJIT,
LLVMIRReader, LLVMAsmParser, LLVMLineEditor, LLVMMCAnalysis,
LLVMMCDisassembler, LLVMInstrumentation, LLVMInterpreter, LLVMCodeGen,
LLVMScalarOpts, LLVMInstCombine, LLVMTransformUtils, LLVMipa, LLVMAnalysis,
LLVMProfileData, LLVMMCJIT, LLVMTarget, LLVMRuntimeDyld, LLVMObject,
LLVMMCParser, LLVMBitReader, LLVMExecutionEngine, LLVMMC, LLVMCore,
LLVMSupport
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
I really want to use this package on my Windows, but nothing seems to work (I tried everything like --extra-lib-dirs and compiled also with MinGW and VS - the same problem).
I can't accept the fact that it won't install. I mean, there must be some way to fix Setup.hs from this cabal package or something. Does anyone have an idea what can be wrong with cabal in this case and how can I try to workaround this? I don't know how exactly cabal works, maybe someone with this knowledge will have an idea? Or maybe there is a way to do this without cabal?
Ok, i've managed to build it and, i think, found the root of the issue.
First, steps to build:
Get the MinGW. My installation of MinGW has gcc 4.8.
Get 32-bit MinGHC.
Compile LLVM 3.5 with MinGW's gcc and install it somewhere.
Copy contents of MinGW installation directory into MinGHC Install
Dir\ghc-7.10.2\mingw, replacing conflict files.
In the command line set your PATH so it has haskell toolset from
MinGHC (i recommend using switch .bat scripts) and llvm-config.exe.
Get the llvm-general package source either using cabal fetch or
downloading via browser from hackage.
Replace cc-options: -std=c++11 line of llvm-general.cabal with
cc-options: -std=gnu++11.
Finally, cabal configure and cabal build should work.
I have been changing my build environment many times, so if this doesn't work for you let me know, i probably forgot something.
Now let's go into details.
What we thought is a bug of cabal is not, actually. The problem is that both stack and MinGHC (and Haskell Platform, i guess) use quite old gcc - 4.6. This gcc has even two defects:
It doesn't support -std=c++11 and LLVM 3.5 can't be built using it.
As a consequence, this gcc can't be used by ghc when compiling
llvm-general, because it can't parse LLVM headers properly.
Even if it could, its linker can't link against LLVM libs compiled by
MinGW using gcc 4.8. This is why cabal was telling you it
couldn't find LLVM libs. I've hacked Setup.hs so that it wouldn't
look for these libs, but pass -lLLVMSomething to linker via -pgml
ghc option. This lead to clear error message:
ld.exe: ignoring libLLVMSupport.a ...
ld.exe: can't find -lLLVMSupport
So, the cabal was actually finding these libs, but was dropping them because they couldn't be linked to.
Ideally, the solution would be to update mingw distribution used by stack/MinGHC. But as a workaround you can just replace old gcc with new one.
Finally, -std=gnu++11 is used because current MinGW release is affected by this bug, which prevents compilation of c++ bits of the package. Whew, that was a long way.

Problems installing gtk2hs on windows

I have decided to try to install gtk2hs on my Windows 8 (64 bit) machine. I am relying on the lastest Haskell Platform distribution.
So, I go on the wiki, and follow the instructions. I get gtk+ 32-bit distribution, version 2.24, in the all in one bundle. I unpack it correclty, set up PATH to point to gtk/bin, and create INCLUDE and LIB variables to point respectively to gtk/include and gtk/lib (this step does not seem necessary, but it can't hurt!)
I then verify all is in order by invoking
pkg-config --modversion gtk+-2.0
and the terminal happly chirps back
2.24.10
Great!
Then, I run cabal install
gtk2hs-buildtools
and that also goes well.
But then, when I run cabal install gtk, it complains that glib fails to install, because it can't find some C dependencies. I try to isolate the problem by running
cabal install glib
and get the following:
C:\Users\Federico>cabal install glib
Resolving dependencies...
Configuring glib-0.13.1.0...
Failed to install glib-0.13.1.0
Last 10 lines of the build log ( C:\Users\Federico\AppData\Roaming\cabal\logs\gl
ib-0.13.1.0.log ):
[1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist\setup-wrapper\Gtk2HsS
etup.o )
[2 of 2] Compiling Main ( SetupMain.hs, dist\setup-wrapper\Main.o )
Linking dist/setup-wrapper\setup.exe ...
Configuring glib-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
* Missing C libraries: gobject-2.0, gthread-2.0, glib-2.0, intl
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
cabal: Error: some packages failed to install:
glib-0.13.1.0 failed during the configure step. The exception was:
ExitFailure 1
But this is utter crap! I KNOW the libraries are there. I can see them, in the gtk/bin folder! I re-check my path, and all is good. They are visible, in path. so is include, and lib. All of it. And yet, cabal complains it can't find them.
But this isn't the scariest bit yet...I download the 64-bit of the library, version 2.16...simply swap the two gtk folders...and now, cabal happly builds the whole thing! Of course, it's unsuable, because ghc on the plaftorm is 32-bit and the libraries are 64-bit, so ghc fails to link against it...but at least cabal was pleased.
I then remove glib, cairo, pango, gtk etc, and go about trying installing again, 2.16, 32-bit. And surely, cabal complains about C dependencies missing.
At this point, befuddled by this kafkian situation, I turn to the wisdom of stack overflow!
Is cabal trolling me? Are the error messages misleading? Or am I missing something obvious?
Thanks to all for the help!
If you are using 64 bit version of GHC, you want to use 64 bit version of gtk as well.
You can download it on this link. Scroll down a bit and download 2.x (not 3.x) all in one bundle, don't download 2.16:
http://www.gtk.org/download/win64.php
Above is no longer an option. You can try installing MSYS and than using MSYS console with pacman package manager to install gtk dev library on windows (I haven't tried it yet though). This pretty much sucks in my opinion.

Installing GLUT fails due to missing foreign library - ghc7.8

I tried cabal install GLUT which gave the following:
Setup: Missing dependency on a foreign library:
* Missing C library: glut32
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.
So I thought, ok, lets get the sources and point cabal to the directories. I first tried freeglut and then the following
cabal install GLUT --extra-include-dirs="<path to freeglut>\include"
--extra-lib-dirs="<path to freeglut>\src"
Same thing, so I thought maybe it doesn't work with freeglut, and got glut:
cabal install GLUT --extra-include-dirs="<path to glut>\include"
--extra-lib-dirs="<path to glut>\lib"
When this doesn't work, I try to download the source and cabal install inside the directory, then runghc Setup configure. Then thinking that there is some parse error of the paths, I try every possible way of writing a file path known to man; quotes, no quotes, backslashes, double backslashes, forward slashes, and every combination of the above. I even placed all the files on my PATH in hopes it would find them. All other options exhausted, I proceeded to sacrifice a goat to satan, but still no dice.
The question is, what do I have to do to convince ghc to find this library? (this is windows 7)
You need to make the libglut32.a import library accessible to the compiler (see this answer for information about what import libraries are). Just copy it under $GHCDIR/mingw/lib. Alternatively, try the Haskell Platform installer, which ships with a pre-compiled version of the GLUT bindings.

How to tell Autotools Build System (Guile 1.8.8) Where Libtool is Installed?

I am trying to build Guile 1.8.8 from source. I am stuck at the point where the build system is looking for libtool. I have installed it in a non-standard location.
I have already built Guile 2.0.11. In 2.0.11 build system, there is an explicit flag to configure --with-libltdl-prefix, which I think tells the build system where libtool is installed.
For Guile 1.8.8, I have Libtool installed in a non-standard location. How do I tell the build system where it is installed?
I am specifically getting error messages like:
libguile/Makefile.am:40: Libtool library used but `LIBTOOL' is undefined
libguile/Makefile.am:40: The usual way to define `LIBTOOL' is to add `LT_INIT'
I think in general this is a question regarding one or more of the autotools and how the build system finds programs / headers / libraries in non-standard locations.
This link is informative: How to point autoconf/automake to non-standard packages
Find the directory where *.m4 exists, which corresponds to libtool, or package which is in non-standard location.
export ACLOCAL_PATH=/path/to/m4/file
cd /path/to/configure.[in,ac]
autoreconf -if
./configure

Building Pango with Cairo support

I'm attempting to build a new version of wireshark 1.10 on a RHEL5 box with the intent of making an RPM so that customers that I support can install it. Possibly others if I can find a place to host it.
WS1.10 depends on GTK+ as well as several other libraries that aren't supported by the available rpm packages. Therefore, I have to build them by hand. GTK+ needs pango(1.24.5) with cairo(1.8.8) support.
After having built and installed a newer version of cairo from source, a ./configure of pango gives the following error
checking for CAIRO... yes
checking which cairo font backends could be used... none
configure: Disabling cairo support
and then at the end ./configure displays
configuration:
backends: X
I can verify that Cairo is installed by looking at the pkg_config in my /usr/local/lib.
I've even taken a look at the pango config.log. But I don't see anything that is any different then the messages I copypasta'ed above.
What are some places I should be looking to figure out a less terse error message? I'm kind of at a loss troubleshooting this.
I encountered this issue today and solved it by installing HARFBUZZ, which is mentioned in the README file of Pango. After installation of Harfbuzz we have access to FreeType. So follow this procedure:
Build and install FreeType
Build and install fontconfig
Build and install Cairo (after ./configure please make sure freetype and fontconfig are found)
Build and install Harfbuzz
Build and install Pango
In case of you still have problems even though you are following the guideline of Xiao Jia, take care to look into config.log. It will help you to find out why the package does not find particular components on your system. In my case the fontconfig-devel and freetype-devel package from default repository of my distro was too old.
I could manage it by installing the whole stack into a location outside of /usr (not that difficult as it sounds) by adding configuration file to /etc/ld.so.conf.d and a environment expanding script to /etc/profile.d.

Resources