Is ghc-options not working correctly? #2708

Closed
Prillan opened this Issue Oct 13, 2016 · 12 comments

Comments

Projects
None yet
5 participants
@Prillan

Prillan commented Oct 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Oct 16, 2016

Collaborator

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

Collaborator

mgsloan commented Oct 16, 2016

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

@mgsloan mgsloan added this to the Support milestone Oct 16, 2016

@Prillan

This comment has been minimized.

Show comment
Hide comment
@Prillan

Prillan Oct 17, 2016

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.

Prillan commented Oct 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Oct 17, 2016

Collaborator

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

Collaborator

mgsloan commented Oct 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Prillan

Prillan Oct 19, 2016

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?

Prillan commented Oct 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Oct 19, 2016

Collaborator

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

Collaborator

mgsloan commented Oct 19, 2016

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

@NickMcAvoy

This comment has been minimized.

Show comment
Hide comment
@NickMcAvoy

NickMcAvoy Oct 28, 2016

I'm hitting precisely this issue.

I'm hitting precisely this issue.

@NickMcAvoy

This comment has been minimized.

Show comment
Hide comment
@NickMcAvoy

NickMcAvoy Oct 29, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@NickMcAvoy

NickMcAvoy Oct 29, 2016

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...

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

This comment has been minimized.

Show comment
Hide comment
@borsboom

borsboom Dec 19, 2016

Contributor

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).

Contributor

borsboom commented Dec 19, 2016

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).

@lwm

This comment has been minimized.

Show comment
Hide comment
@lwm

lwm Sep 12, 2017

Member

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

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

Member

lwm commented Sep 12, 2017

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

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

@lwm lwm added the type: bug label Sep 12, 2017

@mgsloan

This comment has been minimized.

Show comment
Hide comment
@mgsloan

mgsloan Jan 16, 2018

Collaborator

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

Collaborator

mgsloan commented Jan 16, 2018

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

@mgsloan mgsloan closed this Jan 16, 2018

@Prillan

This comment has been minimized.

Show comment
Hide comment
@Prillan

Prillan Jan 17, 2018

Wow, sorry, totally forgot about this. I'll re-open it if I encounter this issue again.

Prillan commented Jan 17, 2018

Wow, sorry, totally forgot about this. I'll re-open it if I encounter this issue again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment