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

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:

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

Use user-local Stack:

export PATH=$HOME/.local/bin:$PATH            # stack 3.7.1
export STACK_ROOT=/mnt/nas/vol2/fiza/stackroot

Build:

stack --allow-different-user --stack-root "$STACK_ROOT" --work-dir .stack-work-fiza build

Observe link failure using conda toolchain:

/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:

Error: [S-7441]
Raw command: /usr/bin/tar Jxf /home/<user>/.stack/programs/x86_64-linux/ghc-8.10.2.tar.xz

Using an absolute --work-dir:

stack --work-dir /mnt/nas/vol2/fiza/vpf-stack-work build

yields:

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

If a non-ASCII space is copied before --, e.g. exec -- vpf-class:

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:

/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:

/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.

# 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

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.