“Stack 3.7.1: linker (-lgmp) failure & wrong toolchain when building vpf-class project”

### General summary/comments (optional)
Trying to build and run the `vpf-tools` project (`exec target vpf-class`) on a shared HPC host. I upgraded to Stack 3.7.1 in my home (`~/.local/bin/stack`), but I’m seeing a few rough edges:

1. GHC setup/build fails when a conda toolchain is present: the link step uses x86_64-conda-linux-gnu-cc and errors with cannot find -lgmp. Even after providing GMP via conda, Stack/GHC still prefer the conda toolchain unless I scrub env vars.
2. GHC sanity check and setup produce confusing failures if libtinfo.so.5/GMP are missing.
3. If STACK_ROOT isn’t exported in the shell, Stack quietly falls back to ~/.stack and tries to unpack GHC there (low-space home), leading to tar Jxf … failures.
4. In Stack 3.x, --work-dir no longer accepts absolute paths; the error is correct but took a while to discover (docs/UI hint could be clearer).
5. When a non-ASCII space sneaks into exec --, Stack treats it like runghc and the “Invalid argument vpf-class” message is non-obvious; a more explicit hint would help.

Not all of these are “bugs” per se, but #1 (toolchain contamination) and #5 (diagnostic clarity) might be actionable.

### Steps to reproduce

Ensure a conda environment is active (e.g., `base`), so `x86_64-conda-linux-gnu-cc` is on `PATH/CC`.

Clone project and cd:

~~~text
git clone https://github.com/biocom-uib/vpf-tools
cd vpf-tools
~~~

Use user-local Stack:
~~~text
export PATH=$HOME/.local/bin:$PATH # stack 3.7.1
export STACK_ROOT=/mnt/nas/vol2/fiza/stackroot
~~~

Build:
~~~text
stack --allow-different-user --stack-root "$STACK_ROOT" --work-dir .stack-work-fiza build
~~~

Observe link failure using conda toolchain:
~~~text
/usr/local/miniconda3/.../ld: cannot find -lgmp
`x86_64-conda-linux-gnu-cc' failed in phase `Linker'. (Exit code: 1)
~~~

(If `STACK_ROOT` is not set) Stack falls back to `~/.stack` and GHC unpack fails in a low-space home:
~~~text
Error: [S-7441]
Raw command: /usr/bin/tar Jxf /home//.stack/programs/x86_64-linux/ghc-8.10.2.tar.xz
~~~

Using an absolute `--work-dir`:
~~~text
stack --work-dir /mnt/nas/vol2/fiza/vpf-stack-work build
~~~

yields:
~~~text
option --work-dir: ... Stack will not accept an absolute path.
~~~

If a non-ASCII space is copied before `--`, e.g. `exec -- vpf-class`:
~~~text
stack: WARNING! Using runghc ...
Invalid argument `exec --'
Error executing interpreter command: stack exec -- vpf-class ...
~~~

Project `stack.yaml` is the one in `biocom-uib/vpf-tools` (`resolver` targets GHC 8.10.x).

### Expected

Stack/GHC should ignore conda’s compiler/toolchain by default (or provide a clear hint) and use a system toolchain, or error with a message pointing to GMP/ncurses requirements and how to avoid conda toolchain contamination.

Clearer diagnostics when `--work-dir` is absolute (e.g., print “use a relative path like .stack-work-user”).

If a non-ASCII space appears in exec --, emit a specific message (“non-ASCII whitespace detected near --; please retype with ASCII space”).

### Actual

Link step fails with:

~~~text
/usr/local/miniconda3/.../ld: cannot find -lgmp
`x86_64-conda-linux-gnu-cc' failed in phase `Linker'. (Exit code: 1)
~~~

GHC sanity check complains about:
~~~text
/lib64/libtinfo.so.5: no version information available ...
~~~

and then fails to link if GMP/ncurses-compat are missing.

If `STACK_ROOT` is not exported, Stack tries to unpack GHC into `~/.stack` and fails (`tar Jxf ... ExitFailure 2`) due to space/corruption.

Absolute `--work-dir` is rejected (as designed) but the error took time to interpret.

Non-ASCII space in `exec --` produces runghc invocation and “Invalid argument exec --”, which is confusing.

~~~text
# conda active; toolchain visible; missing system gmp/libtinfo
stack --allow-different-user --stack-root "$STACK_ROOT" --work-dir .stack-work-fiza build --verbose
~~~

### Stack version
~~~text
stack --version
Version 3.7.1, Git revision cfae313a06ea9f7278e0ac55a58341fa0440f1aa x86_64 hpack-0.38.1
~~~

### Method of installation

Official binary via stack upgrade (placed at ~/.local/bin/stack).
A legacy system-wide 2.7.3 exists in /usr/local/bin (cannot be overwritten; no sudo).

### Platform
x86_64 Linux on an HPC node (RHEL/CentOS/Rocky family; no sudo).
Conda is commonly used on the cluster; envs expose x86_64-conda-linux-gnu-cc.