4

I have read NixOS, Haskell, opengl : problems with building and running openGL programs and all the other corresponding issues, but I can't get a simple Haskell gloss project (that used to work a few months ago) to work.

Using a github project

Try the following:

$ git clone https://www.github.com/turion/rhine
$ cd rhine/
$ cd rhine-gloss/
$ stack build
$ stack exec rhine-gloss-gears 
freeglut (rhine-gloss-gears):  ERROR:  Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow

This project uses the stack nix integration as explained in this answer, but since mesa has been renamed recently, the relevant part in stack.yaml is now:

nix:
  enable: true
  packages: [libGL libGLU freeglut]

From scratch

Make sure you have cabal, stack and nix installed. Then follow these commands:

$ mkdir tempgloss
$ cd tempgloss

Create two files with these contents:

$ cat Main.hs 
import Graphics.Gloss
main = display (InWindow "Nice Window" (200, 200) (10, 10)) white (Circle 80)

$ cat stack.yaml 
resolver: lts-12.10
nix:
  enable: true
  packages: [libGL libGLU freeglut]

Now execute:

$ cabal init --is-executable -n --main-is=Main.hs -d gloss -d base -l MIT
[...]
$ stack build
[...]
$ stack exec tempgloss

What's wrong here?

Turion
  • 5,684
  • 4
  • 26
  • 42
  • I'd do it step by step, since there are so many abstractions at play here. Can you run some OGL diag and verify that the OpenGL actually works (with e.g. `glxgears`)? Once you confirm that, try running a freeglut example. Once that works, move to Haskell. Well, that's what I'd do, anyway. – Bartek Banachewicz Sep 27 '18 at 09:47
  • @BartekBanachewicz, I don't code in C. – Turion Sep 27 '18 at 09:50
  • @BartekBanachewicz, `glxgears` works as expected. (Installed as a package, not compiled from source) – Turion Sep 27 '18 at 09:51
  • Doesn't matter how it's installed, if it works at least your driver/device is fine. Next step would be freeglut; again, I'd recommend building some simple test program [like this one](https://www.badprog.com/c-opengl-checking-the-freeglut-glew-and-opengl-version) and running it. – Bartek Banachewicz Sep 27 '18 at 09:56
  • Are you using NixOS or Nix with some other distribution? If you are using Nix with some other distribution, you can't really run things, that are hardware accelerated, without some hackery. (Nix tries to bring its own graphics driver, which isn't compatible with your kernel and or X server). – typetetris Sep 27 '18 at 12:17
  • @Krom, NixOS. But that's also interesting to know. How would someone with nix on a different distribution solve this? – Turion Sep 27 '18 at 13:24
  • Please include enough information in the question itself (not offsite resources) to reproduce your issue. – Daniel Wagner Sep 27 '18 at 13:27
  • 2
    You can use http://github.com/guibou/nixGL to run any nix OpenGL application on a distribution which is not nixos. – Guillaum Sep 27 '18 at 13:32
  • @DanielWagner, I'm trying, but I'm running into (separate) stack problems right now, see https://github.com/commercialhaskell/stack/issues/4322. – Turion Sep 27 '18 at 14:34
  • @DanielWagner, now I have a MWE. – Turion Sep 27 '18 at 15:14

2 Answers2

1

(This solution is deprecated in favor of my other solution which uses nixGL)

The issue is that stack is overriding the LD_LIBRARY_PATH of your nixos installation. by default it contains something such as /run/opengl-driver/lib:/run/opengl-driver-32/lib and it is override by stack with the path to the library provided by stack, for me it contains: /nix/store/v1d3fmjjqzd1wh84w8dmy4i3hxzgaybf-libGL-1.0.0/lib:/nix/store/y9s4bbn6j54flhpggccrmjd7cv3nkw60-glu-9.0.0/lib:/nix/store/jx7018a4yvd0x79qwp8ad15h5isy1ny3-freeglut-3.0.0/lib:/nix/store/5z8gx1bjw5s0q96n191k0a8caqr4r580-ghc-8.4.3/lib:/nix/store/yypprmw8hrmvwyhhz23w8z25yjvdhnxb-git-2.18.0/lib:/nix/store/iw94llkj05wgaz268mlzvgx8jkbi1ss0-gcc-wrapper-7.3.0/lib:/nix/store/rxaclc3vhxbzgfllv7601i85z854h48a-gmp-6.1.2/lib

I don't have an easy solution, that's actually painful that stack does not change the rpath of your binary and instead override LD_LIBRARY_PATH.

My quick and dirty solution:

  • a) Get the LD_LIBRARY_PATH from inside stack:

stack exec -- env | grep LD_LIBRARY_PATH LD_LIBRARY_PATH=/nix/store/v1d3fmjjqzd1wh84w8dmy4i3hxzgaybf-libGL-1.0.0/lib:/nix/store/y9s4bbn6j54flhpggccrmjd7cv3nkw60-glu-9.0.0/lib:/nix/store/jx7018a4yvd0x79qwp8ad15h5isy1ny3-freeglut-3.0.0/lib:/nix/store/5z8gx1bjw5s0q96n191k0a8caqr4r580-ghc-8.4.3/lib:/nix/store/yypprmw8hrmvwyhhz23w8z25yjvdhnxb-git-2.18.0/lib:/nix/store/iw94llkj05wgaz268mlzvgx8jkbi1ss0-gcc-wrapper-7.3.0/lib:/nix/store/rxaclc3vhxbzgfllv7601i85z854h48a-gmp-6.1.2/lib

  • b) get your current LD_LIBRARY_PATH:

$ echo $LD_LIBRARY_PATH /run/opengl-driver/lib:/run/opengl-driver-32/lib

  • c) get the real path of your executable

$ stack exec --no-nix-pure which rhine-gloss-gears /tmp/rhine/rhine-gloss/.stack-work/install/x86_64-linux-nix/nightly-2018-09-26/8.4.3/bin/rhine-gloss-gears

here, --no-nix-pure allows stack to see which which should be available in your current environment.

d) concatenate all of that, using:

LD_LIBRARY_PATH=yourLD_LIBRARY_PATH:theOneFromStack the_executable_path

Exemple:

LD_LIBRARY_PATH=/run/opengl-driver/lib:/run/opengl-driver-32/lib:/nix/store/v1d3fmjjqzd1wh84w8dmy4i3hxzgaybf-libGL-1.0.0/lib:/nix/store/y9s4bbn6j54flhpggccrmjd7cv3nkw60-glu-9.0.0/lib:/nix/store/jx7018a4yvd0x79qwp8ad15h5isy1ny3-freeglut-3.0.0/lib:/nix/store/5z8gx1bjw5s0q96n191k0a8caqr4r580-ghc-8.4.3/lib:/nix/store/yypprmw8hrmvwyhhz23w8z25yjvdhnxb-git-2.18.0/lib:/nix/store/iw94llkj05wgaz268mlzvgx8jkbi1ss0-gcc-wrapper-7.3.0/lib:/nix/store/rxaclc3vhxbzgfllv7601i85z854h48a-gmp-6.1.2/lib /tmp/rhine/rhine-gloss/.stack-work/install/x86_64-linux-nix/nightly-2018-09-26/8.4.3/bin/rhine-gloss-gears

Guillaum
  • 170
  • 6
0

I'm just pushed a new version of nixGL: http://github.com/guibou/nixgl` which allows you to run your program as:

stack exec --no-nix-pure nixGLIntel rhine-gloss-gears

(replace nixGLIntel by nixGLNvidia or nixGLNvidiaBumblebee if needed).

Guillaum
  • 170
  • 6
  • Why is nixGL not part of nixpkgs? Or rather, why isn't the fix from nixGL in nixpkgs? – Turion Sep 27 '18 at 14:10
  • Well, I should definitely submit it as a `nixpkgs` package. However that's not trivial to fix everything because it depends on the hardware AND the version of `nixpkgs` an application is built with. For example, if you have a clone of `nixpkgs` from last week and a nvidia driver, you'll need a different build of `nixGL` than me, who use a more recent clone of `nixpkgs` and an intel driver. – Guillaum Oct 02 '18 at 11:05