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

Failed to build Stack v1.1.0 on armv7 with Raspbian Jessie, GHC 7.10.3 & Cabal 1.22.8 #2096

Closed
blitzcode opened this issue May 4, 2016 · 4 comments
Milestone

Comments

@blitzcode
Copy link

I'm trying to build stack on an RPi 3 and I got this error:

Building stack-1.1.0...
Preprocessing library stack-1.1.0...
[53 of 86] Compiling Stack.Constants  ( src/Stack/Constants.hs, dist/build/Stack/Constants.o )
src/Stack/Constants.hs:291:7:
    cannot find normal object file `dist/build/Stack/Types/PackageName.dyn_o'
    while linking an interpreted expression

From what I understand, this is because TH needs to load some of stack's modules dynamically to run. If I build with --ghc-options=-dynamic-too, at least this error disappears. Later the linking step fails with thousands of errors like this:

/usr/bin/ld.gold: warning: cannot scan executable section 1 of /home/pi/.cabal/lib/arm-linux-ghc-7.10.3/filelock-0.1.0.1-0GuYZFry5kL0ASYgccAvYE/libHSfilelock-0.1.0.1-0GuYZFry5kL0ASYgccAvYE.a(Flock.o) for Cortex-A8 erratum because it has no mapping symbols.

But I guess at least that is a GHC bug.

I don't know if this is an issue with GHC, Cabal or the way stack's project is setup. I was able to compile all of stack's dependencies (a fairly significant and representative amount of code), so I assume the GHC/Cabal here on armv7 is not fundamentally broken.

Googling for this error leads to a lot of bug reports and discussions, and it's hard for me to figure out who's at fault there. I'd really appreciate a permanent fix for this, or an explanation that would allow me to file a bug report with the appropriate culprit.

Any help with getting stack compiled & build on ARM would be much appreciated.

@mgsloan
Copy link
Contributor

mgsloan commented May 4, 2016

Perhaps we should pass -dynamic-too. This page says that cabal passes it when the compiler supports it, but I'm not sure if that happens at the Cabal level or the cabal-install. I thought it was already happening - TH definitely works.

It's quite possible that this is a regression in Cabal, I am currently using 1.22.5.0 and do not encounter these issues.

Not sure what's going on the the ld issue, sorry, I don't know much about using ARM.

@mgsloan mgsloan added this to the Support milestone May 4, 2016
@blitzcode
Copy link
Author

I've never seen this error before and used plenty of TH, I'm pretty sure it's a combination of ARM + whatever other factors. The main reason I filed a bug for stack is that I managed to build all of stack's dependencies just fine, so there must be something different about how stack is setup. Could very well be a GHC/Cabal issue, I really don't know.

@blitzcode
Copy link
Author

the ld issue is about this:

https://phabricator.haskell.org/D1599
https://ghc.haskell.org/trac/ghc/ticket/11205

A workaround is to build with cabal install -j --dependencies-only --disable-library-stripping --disable-executable-stripping and/or setting executable-stripping: False + library-stripping: False in Cabal's config.

Then stack can be build. The next problem is stack itself lacks this flag, so it can't be used to build anything. Also see #1342

@mgsloan
Copy link
Contributor

mgsloan commented May 5, 2016

Ok, cool, sounds like you figured it out!

@mgsloan mgsloan closed this as completed May 5, 2016
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

2 participants