Is ghc-options not working correctly?

[Prillan]

I'm trying to get stack + ghc running on my raspberry pi 3 and I'm almost there.

I need to specify the ghc-option -opta-march=armv7-a (found it here)

I can get it building with

$ stack ghc -- -opta-march=armv7-a Test.hs
Run from outside a project, using implicit global project config
Using resolver: lts-7.3 from implicit global project's config file: /home/pi/.stack/global-project/stack.yaml
[1 of 1] Compiling Main             ( Test.hs, Test.o )
Linking Test ...

But I can't seem to get it working together with stack, here's my ~/.stack/config.yaml

ghc-options:
  "*": -opta-march=armv7-a
apply-ghc-options: everything

And output from stack build text

 $ stack build text
Run from outside a project, using implicit global project config
Using resolver: lts-7.3 from implicit global project's config file: /home/pi/.stack/global-project/stack.yaml
[1 of 1] Compiling Main             ( /tmp/stack9073/Setup.hs, /tmp/stack9073/Setup.o )
/tmp/ghc9102_0/ghc_6.s: Assembler messages:

/tmp/ghc9102_0/ghc_6.s:41:0: error:
     Error: selected processor does not support `movw r7,:lower16:stg_bh_upd_frame_info' in ARM mode

/tmp/ghc9102_0/ghc_6.s:42:0: error:
     Error: selected processor does not support `movt r7,:upper16:stg_bh_upd_frame_info' in ARM mode

/tmp/ghc9102_0/ghc_6.s:45:0: error:
     Error: selected processor does not support `movw r7,:lower16:base_GHCziTopHandler_runMainIO_closure' in ARM mode

/tmp/ghc9102_0/ghc_6.s:46:0: error:
     Error: selected processor does not support `movt r7,:upper16:base_GHCziTopHandler_runMainIO_closure' in ARM mode

/tmp/ghc9102_0/ghc_6.s:47:0: error:
     Error: selected processor does not support `movw r8,:lower16:Cabalzm1zi24zi0zi0_DistributionziSimple_defaultMain_closure' in ARM mode

/tmp/ghc9102_0/ghc_6.s:48:0: error:
     Error: selected processor does not support `movt r8,:upper16:Cabalzm1zi24zi0zi0_DistributionziSimple_defaultMain_closure' in ARM mode
`gcc' failed in phase `Assembler'. (Exit code: 1)
Exit code ExitFailure 1 while running ["ghc","-clear-package-db","-global-package-db","-hide-all-packages","-package","base","-package","Cabal-1.24.0.0","/tmp/stack9073/Setup.hs","-o","/home/pi/.stack/setup-exe-cache/arm-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1","-rtsopts"] in /tmp/stack9073/

As the last line is missing my option -opta-march=armv7-a I'm assuming it never reaches GHC, leading me to think that I've either misunderstood how ghc-options and apply-ghc-options work or that there is a bug in stack.

I've also tried running with --force-dirty to no effect.

[mgsloan]

Pinging @dysinger and @borsboom - the ARM stuff is not my area of expertise.

[Prillan]

It is not specific to arm (I believe), I'm just confused why ghc-options isn't working. It seems the options doesn't propagate properly to ghc.

[mgsloan]

It looks like the errors are coming from base and similar packages. Since base is included with ghc, you can't apply ghc-options flags to it.

ghc-options are indeed currently a bit ugly, they don't work perfectly for snapshot dependencies. We really need to address this, hopefully soon - #849

[Prillan]

Just to make sure I understand this:
GHC contains the source for some packages that stack compiles (e.g base). Those packages do not get the flags from stack, correct?

[mgsloan]

Correct! Not 100% sure that is what is happening here, but it seems like it.

[NickMcAvoy]

I'm hitting precisely this issue.

[NickMcAvoy]

I'm having trouble understanding how correctly passing on the ghc-options wouldn't fix this. The error trace helpfully lists exactly the arguments passed to ghc. After capturing the Setup.hs it's trying to compile, I was able to reproduce this manually:

$ ghc -clear-package-db -global-package-db -hide-all-packages -package base -package Cabal-1.24.0.0 /tmp/Setup.hs -o /home/nick/.stack/setup-exe-cache/arm-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 -rtsopts 
[1 of 1] Compiling Main             ( /tmp/Setup.hs, /tmp/Setup.o )
/tmp/ghc10351_0/ghc_6.s: Assembler messages:

/tmp/ghc10351_0/ghc_6.s:41:0: error:
     Error: selected processor does not support ARM mode `movw r7,:lower16:stg_bh_upd_frame_info'

/tmp/ghc10351_0/ghc_6.s:42:0: error:
     Error: selected processor does not support ARM mode `movt r7,:upper16:stg_bh_upd_frame_info'

/tmp/ghc10351_0/ghc_6.s:45:0: error:
     Error: selected processor does not support ARM mode `movw r7,:lower16:base_GHCziTopHandler_runMainIO_closure'

/tmp/ghc10351_0/ghc_6.s:46:0: error:
     Error: selected processor does not support ARM mode `movt r7,:upper16:base_GHCziTopHandler_runMainIO_closure'

/tmp/ghc10351_0/ghc_6.s:47:0: error:
     Error: selected processor does not support ARM mode `movw r8,:lower16:Cabalzm1zi24zi0zi0_DistributionziSimple_defaultMain_closure'

/tmp/ghc10351_0/ghc_6.s:48:0: error:
     Error: selected processor does not support ARM mode `movt r8,:upper16:Cabalzm1zi24zi0zi0_DistributionziSimple_defaultMain_closure'
`gcc' failed in phase `Assembler'. (Exit code: 1)

But by simply adding the missing argument it works fine:

$ ghc -opta-march=armv7-a -clear-package-db -global-package-db -hide-all-packages -package base -package Cabal-1.24.0.0 /tmp/Setup.hs -o /home/nick/.stack/setup-exe-cache/arm-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 -rtsopts 
[1 of 1] Compiling Main             ( /tmp/Setup.hs, /tmp/Setup.o )
Linking /home/nick/.stack/setup-exe-cache/arm-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 ...

I don't think it's related to base being wired-in.

[NickMcAvoy]

Yup, here's an ugly workaround that seems to confirm just passing on the ghc options would work. For me, ~/ghc/bin/ghc is a symlink to ~/ghc/bin/ghc-8.0.1. Instead of a symlink I made it an executable shell script:

!/bin/sh

ghc-8.0.1 -opta-march=armv7-a $@

And then:

$ stack build
[1 of 1] Compiling Main             ( /tmp/stack10569/Setup.hs, /tmp/stack10569/Setup.o )
Linking /home/nick/.stack/setup-exe-cache/arm-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 ...
evergreen-terrace-0.1.0.0: configure
Configuring evergreen-terrace-0.1.0.0...
evergreen-terrace-0.1.0.0: build
Preprocessing library evergreen-terrace-0.1.0.0...
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/arm-linux/Cabal-1.24.0.0/build/Lib.o )
Preprocessing executable 'evergreen-terrace-exe' for
evergreen-terrace-0.1.0.0...
[1 of 1] Compiling Main             ( app/Main.hs, .stack-work/dist/arm-linux/Cabal-1.24.0.0/build/evergreen-terrace-exe/evergreen-terrace-exe-tmp/Main.o )
Linking .stack-work/dist/arm-linux/Cabal-1.24.0.0/build/evergreen-terrace-exe/evergreen-terrace-exe ...
evergreen-terrace-0.1.0.0: copy/register
Installing library in
/mnt/seodaemun/projects/evergreen-terrace/.stack-work/install/arm-linux/lts-7.5/8.0.1/lib/arm-linux-ghc-8.0.1/evergreen-terrace-0.1.0.0-AkJh9idDwA94dRAPZXYkWM
Installing executable(s) in
/mnt/seodaemun/projects/evergreen-terrace/.stack-work/install/arm-linux/lts-7.5/8.0.1/bin
Registering evergreen-terrace-0.1.0.0...

[borsboom]

So it looks to me like the problem is that the ghc-options aren't being passed when compiling the default simple Setup.hs. This is cached globally per Cabal/ghc version and isn't part of any package, so a project's ghc-options don't apply to it (the ghc-options in ~/.stack/config.yaml are defaults for every project

I can think of a couple of ways to change the behaviour that would help:

1. Cache the compiled simple Setup.hs in the project's .stack-work instead of globally, and apply the "*" ghc-options from the project to it. In the future, this would be cached in the implicit snapshot instead.

2. Have a special case where when the global ~/.stack/config.yaml has ghc-options that apply to everything, those options get passed to the simple Setup.hs.

I can't think of any cases where the extra flexibility offered by (1) would be needed (e.g. being able to have different simple Setup.hs options for some projects).

[decentral1se]

I guess this might have been fixed with related work in #849.

@Prillan, can you confirm with a new version of Stack?

[mgsloan]

Closing this due to lack of confirmation. I also think that this may have been an instance of an issue fixed by #3781