"* Missing (or bad) C library: OpenAL32" - from stack build for a haskell project - haskell

I have a stack project using Sound.ALUT. The project was building fine on both Windows and Mac before I added sound. (Sound.ALUT is a library layered over OpenAL.) Got thinks working on MacOS but those changes broke the Windows build. Still builds fine on MacOS.
The offending snippit from the "stack build" console log on Windows looks like this
GLUT > [22 of 24] Compiling Graphics.UI.GLUT.Callbacks.Global
GLUT > [23 of 24] Compiling Graphics.UI.GLUT.Callbacks
GLUT > [24 of 24] Compiling Graphics.UI.GLUT
GLUT > copy/register
GLUT > Installing library in C:\sr\snapshots\87ecdd59\lib\x86_64-windows-ghc-8.10.7\GLUT-2.7.0.16-2jeyeunHWey2D1Huuhst8j
GLUT > Registering library for GLUT-2.7.0.16..
OpenAL > configure
OpenAL > Configuring OpenAL-1.7.0.5...
OpenAL > Cabal-simple_Z6RU0evB_3.2.1.0_ghc-8.10.7.exe: Missing dependency on a foreign
OpenAL > library:
OpenAL > * Missing (or bad) C library: OpenAL32
OpenAL > This problem can usually be solved by installing the system package that
OpenAL > provides this library (you may need the "-dev" version). If the library is
OpenAL > already installed but in a non-standard location then you can use the flags
OpenAL > --extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
OpenAL > library file does exist, it may contain errors that are caught by the C
OpenAL > compiler at the preprocessing stage. In this case you can re-run configure
OpenAL > with the verbosity flag -v3 to see the error messages.
OpenAL >
Progress 10/21
Cleary it can't find OpenAL. I've tried:
installing OpenAL using the Windows installer from https://www.openal.org/downloads
cloning and building openal-soft https://github.com/kcat/openal-soft on windows
setting the --extra-include-dirs and --extra-lib-dirs inslide my stack.yaml to point to where the libraries should be.
I had similar issues getting Sound.ALUT working on the Mac build. In that case building from the sources seemed to solve the problems. I have more trouble building on Windows since the build environment is less familiar. My Windows work has mostly been centered around installing Cygwin and making it look like Unix. But this time, I'm trying to get by on what stack's mingw-w64 provides. I was pulling down things with stack exec -- pacman trying to find something that would install OpenAL as a side effect but no luck.
Some subtleties arise from the fact that stack want to install things in its own self-contained environment. It tries to keep installs localized inside the project directory and not muck around with directories elsewhere. My stack environment looks like this
C:\Users\Mark\slgjff>stack path
snapshot-doc-root: C:\sr\snapshots\aff7b821\doc
local-doc-root: C:\Users\Mark\slgjff\.stack-work\install\f5431f41\doc
local-hoogle-root: C:\Users\Mark\slgjff\.stack-work\hoogle\f5431f41
stack-root: C:\sr
project-root: C:\Users\Mark\slgjff
config-location: C:\Users\Mark\slgjff\stack.yaml
bin-path: .;C:\sr\snapshots\87ecdd59\bin;C:\sr\compiler-tools\x86_64-windows\ghc-8.10.7\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\mingw\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\usr\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\usr\local\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Users\Mark\AppData\Roaming\local\bin;C:\Users\Mark\AppData\Local\Microsoft\WindowsApps
programs: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows
compiler-exe: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin\ghc-8.10.7.exe
compiler-bin: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin
compiler-tools-bin: C:\sr\compiler-tools\x86_64-windows\ghc-8.10.7\bin
local-bin: C:\Users\Mark\AppData\Roaming\local\bin
extra-include-dirs: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\include
extra-library-dirs: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\lib, C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\bin
snapshot-pkg-db: C:\sr\snapshots\87ecdd59\pkgdb
local-pkg-db: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8\pkgdb
global-pkg-db: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\lib\package.conf.d
ghc-package-path: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8\pkgdb;C:\sr\snapshots\87ecdd59\pkgdb;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\lib\package.conf.d
snapshot-install-root: C:\sr\snapshots\87ecdd59
local-install-root: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8
dist-dir: .stack-work\dist\274b403a
local-hpc-root: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8\hpc
local-bin-path: C:\Users\Mark\AppData\Roaming\local\bin
ghc-paths: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows
I'm not sure the configure needs to be happy. I wish I could construct a checklist run through, but I don't understand enough to write that checklist. Do it need the C source for header files? Don't know. Certainly it must need the .lib and .dlls on the path somewhere. But which path exactly?
My package.yaml -- which works fine on MacOS
ghc-options:
#- -dynamic
- -static
dependencies:
- base >= 4.7 && < 5
- random
- gloss
- gloss-juicy
- ALUT
library:
source-dirs: src
executables:
slgjff-exe:
main: Main.hs
source-dirs: app
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- slgjff
tests:
slgjff-test:
main: Spec.hs
source-dirs: test
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- slgjff
And my stack.yaml -- which also works fine on MacOS
resolver:
url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/18/24.yaml
packages:
- .
extra-deps:
- gloss-1.13.2.1#sha256:273d02d30e1896932d45424dab6022a16986c0ed3eef6937776b5f40854ce51c,4075
- JuicyPixels-3.3.6#sha256:03bd32c3a884ac8a32f49334f14695469a710945c84cef9a1e059a79ac416996,3911
- gloss-juicy-0.2.3
And because it may be helpful, here are the includes at top of my program.
import System.Exit ( exitSuccess, exitFailure )
import System.IO ( hPutStrLn, stderr )
import Data.List
import Graphics.Gloss
import Graphics.Gloss.Interface.Pure.Game
import Graphics.Gloss.Interface.IO.Game
import Graphics.Gloss.Data.Vector
import Graphics.Gloss.Juicy
import Control.Monad( when, unless )
import Sound.ALUT as S
I got so desperate I stuck C:/Windows/System32 on the path and almost spilled my drink when the build tried to delete files from C:/Windows/System32. So, I took that out. Running out of ideas.
My sense is that out of inexperience with ghc on Windows, I must be missing something that would be really obvious to someone with more experience. Thanks in advance for any insights.
P.S. I created a stripped down version of the project and put it up on github at https://github.com/markcornwell/alut-glitch
See the README for the project for instruction on how to reproduce the error.

Related

Cannot install z3 package for Haskell on Windows 10

I'm trying to install a project that uses the z3 package under Windows 10 and haskell stack with the following setup:
The z3 precompiled binaries (with includes under ./z3/includes and dll files under ./z3/bin) are located under the project root
myProject/
- app/
- dist/
- src/
- z3/
- package.yaml
- Setup.hs
- stack.yaml
- myProject.cabal
The package.yaml file contains:
dependencies:
- base >= 4.7 && < 5
- containers
- parsec
- z3 <= 408.0
The stack.yaml file contains:
extra-deps:
- z3-408.0#sha256:89bbc2d828dc1fe1f19666e8e501c69ce5d0ed8026e4a02f7eae1e69f4a352af
extra-include-dirs:
- ./z3/include
extra-lib-dirs:
- ./z3/lib
When I try to stack install I get the following error:
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\jmueller\repos\synthImp\.stack-work\logs\z3-408.0.log
z3-408.0: configure
Progress 1/2
-- While building package z3-408.0 using:
<...>
--extra-include-dirs=C:\Users\jmueller\repos\synthImp\./z3/include
<...>
--extra-lib-dirs=C:\Users\jmueller\repos\synthImp\./z3/lib
Configuring z3-408.0...
Cabal-simple_Z6RU0evB_2.4.0.1_ghc-8.6.5.exe: Missing dependency on a foreign
library:
* Missing (or bad) C library: z3
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
library 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.
The extra include and extra lib dirs are there and obviously the include is found too ... there seems to be a problem on the level of the c compiler
I tried both binaries for z3 (x64 and x86) and I don't know how to capture the output of the c preprocessor for further debugging.
Any help is highly appreciated!
Many thanks in advance

Conditional Compilation in Haskell submodule

I'm trying to have a submodule in my program compile conditionally to switch small parts of the code between release builds and development builds.
Currently I'm attempting to use cpphs however when I change the flags passed into GHC to define a variable and change an ifdef statement stack won't recompile those files.
For example, I've got a port number that I want to switch based on which target I have built. The code I have defining this number looks like this.
#ifdef StableRelease
port = 12345
#else
port = 54321
#endif
the stable build has the following options in its cabal file
ghc-options: -threaded -rtsopts -with-rtsopts=-N -pgmP cpphs -optP "-DStableRelease"
When I run stack build though it doesn't seem to actually pre-process the code above.
Does anyone have experience with cpphs or another preprocessing solution?
I would solve this with the help of flags
cppstuf.cabal-file
name: cppstuf
version: 0.1.0.0
...
cabal-version: >=1.10
flag StableRelease {
Description: Stable release settings like port ...
Default: False
}
executable cppstuf
main-is: Main.hs
build-depends: base >=4.9 && <5.00
default-language: Haskell2010
extensions: CPP
if flag(StableRelease) {
GHC-Options: -DSTABLE
}
Main.hs
module Main where
main :: IO ()
main =
#if STABLE
putStrLn "Hello, Haskell!"
#else
putStrLn "Hello, Haskell?"
#endif
and compiling it
stack build
or
stack build --flag cppstuf:stablerelease
Personal Note aside from the answer
I would not use CPP to manage configuration options - either providing command-line options I like optparse-applicative but there is also cmdargs,and or a configuration file I have used configurator for that, but there are several options out there on hackage. One being configurator-ng as #Shersh said - the other one is not being developed anymore.
CPP on the other hand I tend to use for making libraries work across multiple GHC/library versions.
Update - w\ regards to the comment.
If I deliver a program, the operations team should be able to change ports, hostname or handle file location of input files etc. without knowing haskell let alone recompiling a project.
It makes error chasing a lot easier if your production source code does not differ from your development sources, say you would have a postgres db in dev mode, but an oracle in production - you'll never find the oracle specific bug.
For things like optimization levels - I don't mind too much.
But make sure you test multi-threaded stuff properly, I once ran out of file handles because I was opening a lot but not closing fast enough - If your dev-setting is single threaded you'll deliver a bug.

Stack: How to depend on a package during development?

There is a portion of my application that would be better if published to Hackage. I still don't know exactly what it will look like, so I need to make many changes to it while working on my application.
It's very easy to just create a module in my project and iterate there, but I would like to put it in its own project so it can have its own dependencies.
How can I have my project depend on this separate package during development? It should allow for quick iteration. Here's what I tried so far:
# stack.yaml
packages:
- '.'
- location: ../amqp-worker
# my-application.cabal
library
build-depends:
base >= 4.7 && < 5
, amqp-worker
But I get an error when I build:
$ stack build
cra-reporting-0.1.0.0: build
-- While building package cra-reporting-0.1.0.0 using:
/Users/seanhess/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.24.0.0 build lib:cra-reporting exe:cra-reporting-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: /Users/seanhess/projects/simple/cra-reporting/.stack-work/logs/cra-reporting-0.1.0.0.log
Preprocessing library cra-reporting-0.1.0.0...
[8 of 8] Compiling Simple.DataX.Worker ( src/Simple/DataX/Worker.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.0.0/build/Simple/DataX/Worker.o )
/Users/seanhess/projects/simple/cra-reporting/src/Simple/DataX/Worker.hs:6:1: error:
Failed to load interface for ‘Network.Worker’
Perhaps you meant
Network.Socket (needs flag -package-key network-2.6.3.1)
Network.Wreq (from wreq-0.4.1.0)
Network.Socks5 (needs flag -package-key socks-0.5.5)
Use -v to see a list of the files searched for.
The external package seems to build fine if I run stack build from within its project folder.
Both projects are targeting lts-7.3
The above example should work. I attempted this again from scratch and it works fine. The error was due to some kind of build artifact.
If it happened again I would delete .stack-work in the sub-project and rebuild.

How to use stack with nix to build wxHaskell project?

I'm trying to set up a build environment for wxHaskell using Nix and Stack.
I've installed wxWidgets-3.0.2 through nix. This is the relevant portion from by .cabal file
executable hellowx-exe
hs-source-dirs: app
main-is: Main.hs
ghc-options: -threaded -rtsopts -with-rtsopts=-N
build-depends: base
, hellowx
, wx
, wxc
, wxcore
, wxdirect
and the stack.yaml file
resolver: lts-5.0
extra-deps:
- wx-0.92.2.0
- wxc-0.92.2.0
- wxcore-0.92.2.0
- wxdirect-0.92.2.0
I tried adding
nix:
enable: true
packages: [wxwidgets]
but that wasn't the right way apparently.
So I got rid of the nix part in the .yaml file and tried the command $ stack --nix build which resulted in failure. The log file said
[1 of 1] Compiling Main ( /run/user/1000/stack8847/wxc-0.92.2.0/Setup.hs, /run/user/1000/stack8847/wxc-0.92.2.0/.stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/setup/Main.o )
Linking /run/user/1000/stack8847/wxc-0.92.2.0/.stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/setup/setup ...
Error: wx-config not found, please install wx-config before installing wxc
However I do have wx-config and wxwidgets installed through nix. The build process can't find it for some reason. What can I do to set up this build environment? Is there a way to direct the build process to look in the directory containing wx-config? I can't figure out why it can't find it. Its in the PATH.
Ok, I figured it out. I was adding the wrong "attribute name". Here is the correct stack.yaml file
# at this point in time nix supports lts-5.0
resolver: lts-5.0
packages:
-'.'
extra-deps:
- wx-0.92.2.0
- wxc-0.92.2.0
- wxcore-0.92.2.0
- wxdirect-0.92.2.0
# wxwidgets-3.0.2 has the attribute name wxGTK30
# you also need zlib, mesa_noglu and x11
nix:
enable: true
packages: [zlib, wxGTK30, mesa_noglu, x11]
That seems to build everything properly, and I was able to build a minimal window from here (minimal.hs)

How to redistribute wxHaskell apps?

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

Resources