I'm looking at that page, and aside from one slight documentation bug that doesn't really affect anything here it looks correct to me and shouldn't be able to get the wrong executable name unless something has gone wrong inside xmonad's compile logic. Although that also looks out of date: we support stack building directly, so xmonad should use essentially that build script itself when it sees a `stack.yaml` file. You probably want to use the latest version of the install documentation: https://github.com/xmonad/xmonad/blob/master/INSTALL.md#build-using-stack On Sun, Oct 22, 2023 at 11:11 AM Jan Detke wrote:

Brandon Allbery writes:

...

Essentially yes. Arch and derivatives insist on using dynamic linking, and you must rebuild your config after every system update to ensure it still works. We strongly recommend you use `stack` or `cabal` instead, and install `xmonad` and `xmonad-contrib` from Hackage. If you choose not to do so, see

https://wiki.archlinux.org/title/Xmonad#Problems_with_finding_shared_librari...

So I went the route of removing everything related to haskell, ghci and cabal from my system and followed the instructions of installing and setting up xmonad with stack. The installation went through and xmonad is recompiling under the usage of the given bash script (which invokes stack build). There are no errors given to me but I noticed that there is no 'xmonad-x86_64-linux' executable generated in my folder after running the script. In fact there is an executable created called '-lm' but I do not know if this is just an issue related to the filename or something else wrong here.

I followed these instructions on installing xmonad via stack: https://github.com/xmonad/xmonad/blob/883143fd5895e0da4ee8e50722e3011cf30e2c...

Can you help me out here?

Best regards Jan

-- brandon s allbery kf8nh allbery.b@gmail.com

In XDG mode, per the XDG spec executables are not to be stored in config file locations. Since it can be regenerated from `xmonad.hs` when needed, it belongs under `.cache`. In legacy mode (~/.xmonad) the executable is kept next to the `xmonad.hs` file. Your description of running `startx` seems a bit confused to me. Did you run it in the background and then try to run xmonad? This won't work because `startx` can't alter the environment variables of the running shell, so `$DISPLAY` won't be set. You need to run xmonad within the client environment: `startx ~/.cache/xmonad/xmonad-x86_64-linux` (it has to be a full pathname; see the `startx` documentation). On Sun, Oct 22, 2023 at 3:03 PM Jan Detke wrote:

Brandon Allbery writes:

...

I'm looking at that page, and aside from one slight documentation bug that doesn't really affect anything here it looks correct to me and shouldn't be able to get the wrong executable name unless something has gone wrong inside xmonad's compile logic. Although that also looks out of date: we support stack building directly, so xmonad should use essentially that build script itself when it sees a `stack.yaml` file.

You probably want to use the latest version of the install documentation:

https://github.com/xmonad/xmonad/blob/master/INSTALL.md#build-using-stack

...

I found the executable under '$HOME/.cache/xmonad/'. Is this the intendet location for the executable? I assumed that it would reside in the directory where my xmonad.hs and the build script are located.

Additionally, I tried starting xmonad outside of my display manager that did not work out. I will look deeper into xinit for this regard - but as a short notice: I loggend in a tty, ran startx (with some warnings) and then xmonad. The received output was 'xmonad-x86_64-linux: user error (openDisplay)', which indicates that the xserver is not running properly.

I will try to fall back to my display manager by creating a desktop entry for xmonad under '/usr/share/xsessions/', but that is a task for tomorrow.

Thanks again Jan

-- brandon s allbery kf8nh allbery.b@gmail.com

As per the documentation of `startx`, if you do not use a full pathname it runs a default session and passes it your argument as a parameter. Also make sure `~/.xinitrc` is executable (`chmod +x ~/.xinitrc) and that its first line is `#! /bin/bash` or `#! /bin/sh`. On Mon, Oct 23, 2023 at 12:38 PM Jan Detke wrote:

Brandon Allbery writes:

...

Your description of running `startx` seems a bit confused to me. Did you run it in the background and then try to run xmonad? This won't work because `startx` can't alter the environment variables of the running shell, so `$DISPLAY` won't be set. You need to run xmonad within the client environment: `startx ~/.cache/xmonad/xmonad-x86_64-linux` (it has to be a full pathname; see the `startx` documentation).

I thought that I had to start the xserver before invoking 'exec ~/.cache/xmonad/...'' like I would in .xinitrc. Now when I log in and manually run 'startx ~/.cache/xmonad/xmonad-x86_64-linux' it works like a charm. But when I run 'startx .xinitrc' where one line of .xinitrc contains 'exec ~/.cache/xmonad/xmonad-x86_64-linux' the startup of the xserver fails. I also tried giving the full path like 'home/jan/.cache/...' but it still fails. Do I have to wrap the path into quotes for the exec command or what is wrong here?

Best regards Jan

-- brandon s allbery kf8nh allbery.b@gmail.com