Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

with-gcc option is not respected #3902

Closed
wdanilo opened this issue Mar 6, 2018 · 6 comments
Closed

with-gcc option is not respected #3902

wdanilo opened this issue Mar 6, 2018 · 6 comments

Comments

@wdanilo
Copy link

wdanilo commented Mar 6, 2018

Problem description

I'm building a project with some C code and I want to use a specific GCC version. So I'm invoking stack like stack --with-gcc /usr/bin/gcc-6.4.0 .... It seems that stack just does not respect this setting somehow, because it fails with error:

Building library for <libname>...
gcc: error: unrecognized command line option ‘--std=c++17’

What is more interesting:

  1. If I change the GCC path to non-existing one, the build fails earlier with info " Cannot find the program 'gcc'" - which is good, it shows that this option actually makes some effect.
  2. If I change my package.yaml cc-options from --std=c++17 to --version (a little dirty hack), then I can see in my terminal printed gcc (Gentoo 4.9.3 p1.5, pie-0.6.4) 4.9.3 which is my system-wide GCC - so clearly stack uses wrong GCC here.
  3. If I create a local folder (lets call it localbin) and I create symlink gcc -> /usr/bin/gcc-6.4.0 and export it to be on the beginning of $PATH and then invoke stack, everything works.

Stack version

1.6.5

Method of installation

  • Official binary, downloaded from stackage.org or fpcomplete's package repository
@mouse07410
Copy link

I've a somewhat similar problem. I'm on MacOS High Sierra, and use Macports-installed GCC-7.3.0. It needs to invoke Xcode assembler. My workaround was to add -pgma clang to ghc-options: in <package>.cabal file. Perhaps it could work your you...?

@dbaynard
Copy link
Contributor

@wdanilo Is this still an issue for you?

@Mikolaj
Copy link

Mikolaj commented Dec 22, 2021

Hi! Heads up about haskell/cabal#7874, which is a PR solving this ticket that @jberryman has kindly just rebased and we are desperate to merge before it bitrots.

We need to add a small test for that or at least test the branch on the examples you have. Please help!

[edit: was wrong cabal ticket number]

@Mikolaj
Copy link

Mikolaj commented Jan 11, 2022

Please kindly also have a look (and review) at #7900, which provides a test and discusses its result. Last chance to provide feedback before we merge. Thank you!

@Mikolaj
Copy link

Mikolaj commented Jan 12, 2022

@jberryman: thank you for haskell/cabal#7900, which is now merged, which ends the saga! Please, everybody, test and close this issue if it works for you. The feature should be released in cabal 3.8 (no release date planned yet).

@mpilgrem
Copy link
Member

I am closing this issue given the passage of time and the comment about about the resolution of the upstream issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants