In attempting to upgrade a library (haskell-tree-sitter) to a newer Stackage nightly (nightly-2018-05-04, for GHC 8.4, but nightly-2018-04-25 exhibits this problem too), the build process (with a custom Setup.hs) always generates the following errors from clang:
haskell-tree-sitter-0.1.0: configure (lib)
[1 of 2] Compiling Main ( /Users/patrickt/src/haskell-tree-sitter/Setup.hs, /Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup/Main.o )
[2 of 2] Compiling StackSetupShim ( /Users/patrickt/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup/StackSetupShim.o )
Linking /Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup/setup ...
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
These errors also appear when compiling dependent C code in the project itself; I was able to fix them with the following stanza in my stack.yaml:
apply-ghc-options: everything
ghc-options:
$everything: -optc -Wno-unused-command-line-argument
However, I'm unable to figure out how to silence these warnings when building the setup executable. Adding a GHC_OPTIONS stanza to my Setup.hs did not work, nor did adding ccOptions = "-Wno-unused-command-line-argument" to my Setup.hs's libBuildInfo. Short of editing ~/.stack/programs/x86_64-osx/ghc-8.4.1/lib/ghc-8.4.1/settings on every machine we use, is there a way to silence these warnings? This makes upgrading to 8.4 a tricky proposition.
I am running macOS 10.13.4 with stack 1.7.1. The output of clang --version is
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Running with --verbose seems to indicate that the command producing these warnings is
2018-05-04 12:46:29.295442: [debug] Run process: /Users/patrickt/.stack/programs/x86_64-osx/ghc-8.4.2/bin/ghc-8.4.2 --make -odir /Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup -hidir /Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup -i -i. -clear-package-db -global-package-db -package-db=/Users/patrickt/.stack/snapshots/x86_64-osx/nightly-2018-04-25/8.4.2/pkgdb -package-db=/Users/patrickt/src/haskell-tree-sitter/.stack-work/install/x86_64-osx/nightly-2018-04-25/8.4.2/pkgdb -hide-all-packages -package-id=Cabal-2.2.0.1 -package-id=base-4.11.1.0 -package-id=directory-1.3.1.5 -package-id=process-1.6.3.0 -optP-include -optP/Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup/setup_macros.h /Users/patrickt/src/haskell-tree-sitter/Setup.hs /Users/patrickt/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /Users/patrickt/src/haskell-tree-sitter/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/setup/setup -threaded
[email protected]:tree-sitter/haskell-tree-sitter.gittentative-8.4-upgrade branchscript/bootstrap to fetch submodulesstack buildA clean build free of C errors.
Seemingly-unsilenceable errors from clang.
$ stack --version
Version 1.7.1, Git revision 681c800873816c022739ca7ed14755e85a579565 (5807 commits) x86_64 hpack-0.28.2
stack upgrade since.EDIT: fixed repository link
I encounter the same warning when building this branch of my project with recent stack nightly distributions + clang.
Me too.
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
stack from homebrew
haskell-stack: stable 1.7.1 (bottled), HEAD
The Haskell Tool Stack
stack itself says this is an unsupported build! wot?
A follow-up: I've upgraded to stack HEAD (Version 1.8.0, Git revision 252bc7f051f34b1cfc9cb4cfa5ec35b2f8a2d2f6 x86_64 hpack-0.28.2) and still see this error.
I'm getting clang warning in completely new project:
$ stack new newProject
$ cd newProject
$ stack setup
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
$ stack upgrade
Current Stack version: 1.7.1, available download version: 1.7.1
macOS 10.13.4
@ncaq thanks for the reference!
I've managed to fix that warning by editing settings in ~/.stack/programs/... folder. This is where stack installs ghc to isolate it from system-wide ghc
@oluckyman setting:
[...
("C compiler supports -no-pie", "NO"),
...]
in .stack/programs/x86_64-osx/ghc-8.2.2/lib/ghc-8.2.2/settings silenced the warning for me also... and that's a useful file to know about to patch future incompatibilities with the Apple toolchain after updating it (it's not like we've not been here before).
This is probably an upstream issue https://ghc.haskell.org/trac/ghc/ticket/15112 which unfortunately doesn't look near being closed. According to that, there's an incompatibility with XCode's clang. Specifying the c compiler to use may help (although --with-gcc has its own issues, with Cabal).
The workaround looks like the best approach, for now, though there should probably be some documentation fixes for os x.
It may be possible to edit the default settings, though.
@ncaq thanks for the reference!
I've managed to fix that warning by editingsettingsin~/.stack/programs/...folder. This is where stack installsghcto isolate it from system-wideghc
Replacing gcc(clang) in "C compiler command" field with brew installed gcc works for me.
A documentation PR would be good — would @ncaq, @MMMartt or anybody else like to contribute?
Closing as #4392 adds documentation.
Most helpful comment
@oluckyman setting:
in
.stack/programs/x86_64-osx/ghc-8.2.2/lib/ghc-8.2.2/settingssilenced the warning for me also... and that's a useful file to know about to patch future incompatibilities with the Apple toolchain after updating it (it's not like we've not been here before).