The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the more serious of my problems seems to be with GHC. My platform is GHC 6.10.1 under Windows XP. This post boils down to two questions. First, why would GHCi and GHC look for different symbol names when linking, and second, has anybody had any success working with the OpenAL binding on Windows? If I write a program that uses Sound.OpenAL, I can load and run it in GHCi. If I try to compile the same program with ghc --make -lopenal32 audio.hs, I get a raft of errors like this: Linking audio.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(BufferInternal.o):fake:(.text+0x5d): undefined reference to `alIsBuffer' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0x7d): undefined reference to `alcGetContextsDevice' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0xcd): undefined reference to `alcMakeContextCurrent' The names do not exist in openal32.lib. They should all be preceded by an underscore. GHC does the same thing if I convert the .lib file to a .a file. But why would GHCi do the right thing and GHC do the wrong thing? Am I missing a command line switch? I manually changed configure and configure.ac, per the patches (why weren't those applied to the library in Hackage?) to use ccall since OpenAL uses ccall instead of stdcall. Was there another change I should have made? The other problem is that several routines don't work properly because the constants don't get fixed up correctly during the build process. For example, the function marshalFormat in Sound.OpenAL.AL.Format should return 0x1100 when given Word8 as a parameter. It returns -1 instead; the code tells it to, but I assume some sed-like command was supposed to patch that with the right value. Has anybody had any luck getting this to work?