stack picks up wrong ar executable

[arrowd]

On FreeBSD we always have the /usr/bin/ar executable which is a llvm-ar in disguise.

On my system I also have /usr/local/bin/ar executable that comes from the GNU binutils package. My PATH is set up in such a way that the base ar is preferred:

which ar
/usr/bin/ar

However, running stack --system-ghc build on my project results in

base-compat                  > [ 57 of 130] Compiling Data.Ratio.Compat
bsb-http-chunked             > /usr/local/bin/ar: invalid option -- L
bsb-http-chunked             > Usage: /usr/local/bin/ar [emulation options] [-]{dmpqrstx}[abcDfilMNoOPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...

The problem here is that GHC calls ar believing it supports the -L flag, which is true for /usr/bin/ar. But somehow the GNU version gets invoked instead.

Now, in /usr/local/lib/ghc-9.10.3/lib/settings I have

,("ar command", "ar")
,("ar flags", "qcls")
,("ar supports at file", "YES")
,("ar supports -L", "YES")

If I change it to ("ar command", "/usr/bin/ar") the problem goes away.

Stack version

stack --version
Version 3.9.1 x86_64

[hasufell]

Can you reproduce it with just GHC? It seems ghc is installed in /usr/local/bin, maybe there's some logic to prefer the path of the current executable similar to windows.

[arrowd]

Nope, I tried building pandoc using cabal while having binutils' /usr/local/bin/ar and it worked.

[mpilgrem]

@arrowd, I don't know if the following helps track things down:

stack exec -- which ar should tell you what which returns in the Stack environment.

stack path --bin-path should report the PATH in the Stack environment.

[arrowd]

Yep, stack seems to be a culprit:

% echo $PATH
/home/arr/.local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin
% which ar
/usr/bin/ar

% stack path --bin-path
/usr/home/arr/.stack/snapshots/x86_64-freebsd/976638317d45d4f222c7f4cbeb0d017e148a02d04df1390ce85d445c84ca10af/9.10.3/bin:/usr/home/arr/.stack/compiler-tools/x86_64-freebsd/ghc-9.10.3/bin:/usr/local/bin:/home/arr/.local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin
% stack exec -- which ar
/usr/local/bin/ar

% env PATH=/usr/local/bin:/home/arr/.local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin stack exec -- which ar
/usr/local/bin/ar

In first two cases /usr/bin comes before /usr/local/bin, but stack picks up /usr/local/bin regardless of its position in $PATH, as seen in the third case.

[hasufell]

In stack path --bin-path's output /usr/local/bin actually comes before /usr/bin. It's in there twice.

[hasufell]

I'm wondering if somehow local-bin-path is somehow set to /usr/local/bin in which case the behavior would make sense: https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#local-bin-path

[hasufell]

stack/src/Stack/Config.hs

Lines 417 to 421 in 508eaa1

	localBin <-
	case getFirst configMonoid.localBinPath of
	Nothing -> do
	localDir <- getAppUserDataDir "local"
	pure $ localDir </> relDirBin

And it calls getAppUserDataDirectory if unset: https://hackage-content.haskell.org/package/directory-1.3.10.1/docs/System-Directory.html#v:getAppUserDataDirectory

[mpilgrem]

This may be a red herring, but also check that you have not configured extra-path anywhere:

• https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#extra-path