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

[tabby678]

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.

[mpilgrem]

@tabby678, thanks for reporting.

[1] I had not come across Conda before you posted. I will have to read up on it to appreciate what you have experienced. I am open to adding a guide to using Stack with Conda as a separate topic within Stack's online documentation:

• https://docs.haskellstack.org/en/stable/topics/

[2] The guide to manually installing Stack on Linux that is documented here:

• https://docs.haskellstack.org/en/stable/install_and_upgrade/#install-stack

gives some guide to system libraries that are necessary dependencies on various Linux distributions. The Stack installation sh script should install them on popular distributions.

[3] On Unix-like operating systems, the default Stack root is indeed ~/.stack. That is documented here:

• https://docs.haskellstack.org/en/stable/topics/stack_root/#location

[4] Stack's in-app error message if you specify an absolute path with --work-dir is something like:

> stack --work-dir C:\Temp
option --work-dir: Stack failed to interpret the value of the option as a valid
relative path to a directory. Stack will not accept an absolute path. A path
containing a .. (parent directory) component is not valid.

If set, Stack expects the value to identify the location of Stack's work
directory, relative to the root directory of the project or package. Stack
encountered the value:
C:\Temp

What do you consider is missing from that message?

[5] Stack's command line handling is built on top of what is provided by the optparse-applicative library and, I think, that is built on top of the operating system separating a command line into individual arguments. I don't know that it is clever enough to guess that a user has typed a non-white space 'space' character in error. However, I think it is not easy for a user to type a non-white space 'space' character. What happened in your case?