Nested stack exec getting confused #420

Closed
3noch opened this Issue Jun 26, 2015 · 21 comments

Projects

None yet

3 participants

@3noch
Member
3noch commented Jun 26, 2015

On Windows 8.1 64-bit with resolver of LTS-2.14.

> stack --version
Version 0.1.0.0, Git revision d0129beb8d241b65c429708971dcc01529b8b622

> stack --arch=i386 exec -- stack --arch=x86_64 exec -- which ghc
GHC version mismatched, found 7.8.4 (i386), but expected version 7.8.4 (x86_64) (based on resolver setting in C:\Code\windows-client\stack.yaml). Try running stack setup

I would expect that the inner arch override would win out.

EDIT: My original message made no sense. Be sure you read it as it is now.

@3noch
Member
3noch commented Jun 26, 2015

You might not believe that I actually need this to work...but I do.

@3noch
Member
3noch commented Jun 26, 2015

Strangely enough, flipping the overrides works:

> stack --arch=x86_64 exec -- stack --arch=i386 exec -- which ghc
/c/Users/Elliot Cameron/AppData/Local/Programs/stack/i386-windows/ghc-7.8.4/bin/ghc

For some reason stack is defaulting to i386 on my 64-bit machine.

@DanBurton
Contributor

So this bug, as I understand it, is as follows:

stack is not checking for a stack-installed version of ghc under certain circumstances when the "correct version number but wrong arch" ghc is detected on the PATH.

If you manually put the i386 ghc on your path, and then run stack --arch=x86_64 exec -- which ghc, does it work, or does it give the same error?

@snoyberg
Contributor

Isn't the bug just that you used i86_64 instead of x86_64?

You can change the default arch in your stack.yaml. stack defaults to the
architecture it was built with if there's no setting to contradict it.
Using 32 bit by default is actually intentional since it's more well tested.

On Fri, Jun 26, 2015, 6:45 AM Dan Burton notifications@github.com wrote:

So this bug, as I understand it, is as follows:

stack is not checking for a stack-installed version of ghc under certain
circumstances when the "correct version number but wrong arch" ghc is
detected on the PATH.

If you manually put the i386 ghc on your path, and then run stack
--arch=x86_64 exec -- which ghc, does it work, or does it give the same
error?


Reply to this email directly or view it on GitHub
#420 (comment)
.

@3noch
Member
3noch commented Jun 26, 2015

@snoyberg I botched the original issue description. See it as it is now. My apologies.

@3noch
Member
3noch commented Jun 26, 2015

Oh interesting, so if I build stack with 64-bit GHC it's default will change. That makes sense.

@snoyberg
Contributor

What's going on here is that stack only looks at one GHC on the PATH, not multiple. If you use stack to install the 64 bit compiler, it should work. We can discuss having stack fall back, it's not necessarily a bad idea.

@3noch
Member
3noch commented Jun 26, 2015

Looking at only one makes sense, I think, as long as it's the one with highest precedence. I would imagine that each nesting of stack --arch=X exec -- ... would "stack" (pun intended) the right architecture of GHC paths onto the top of the PATH. Is that right? So if the "stacking" is being done right, I would guess that would not be a problem?

@3noch
Member
3noch commented Jun 26, 2015

Interesting insight. Yes, my 64-bit GHC is MinGHC, not stack's installation. So if stack had done it, it would find it properly?

@snoyberg
Contributor

That's correct, and that's why you're seeing the behavior you are: the outer stack exec is sticking the 32-bit compiler on top. The inner stack exec is seeing that one on the PATH, and refusing to use it. Since you have used stack setup to get a 64-bit compiler, it gives up.

@snoyberg
Contributor

Yes, stack's logic is:

  • Check the first GHC on the PATH
  • Otherwise, go through the full list of GHCs we installed to find the one we need

The second action is a lot more efficient than the first since it uses our metadata files, which is why checking an unbounded number of GHCs isn't a problem.

@3noch
Member
3noch commented Jun 26, 2015

So that's why it's not working for me. The GHC on my path is a 64-bit GHC (which stack didn't install), but stack is defaulting to 32-bit GHC (which it did install). So when I just run stack exec -- stack --arch=x86_64 exec -- which ghc it actually starts with the stack-installed one and tries to move back out into the "unknown" but doesn't like that very much.

@3noch
Member
3noch commented Jun 26, 2015

Would it make sense for stack to default to the architecture of the GHC that's already on the PATH, if any?

@snoyberg
Contributor

That's what would happen if we checked multiple GHCs on the PATH. It would require running ghc --info for every single GHC we can find. Doable, but potentially expensive, which is why we don't do that right now.

@3noch
Member
3noch commented Jun 26, 2015

Perhaps only keep looking if something (like a flag or configuration) is asking for a specific arch.

@snoyberg
Contributor

That seems pretty ad-hoc to me to be honest, and likely to cause more confusion rather than less. I'd rather always check all GHCs on the PATH, or never do it, so that we can give people a clear explanation of what's going on.

@3noch
Member
3noch commented Jun 26, 2015

Fair enough...at least give up once you've found what you need.

@3noch
Member
3noch commented Jun 26, 2015

Stack is in a tough spot, since it needs to be both a chicken and an egg.

@snoyberg
Contributor

Maybe a FAQ entry explaining how stack finds GHC would be enough for now. Would you be able to add an entry and link to this discussion?

@3noch
Member
3noch commented Jun 26, 2015

Done.

@snoyberg
Contributor

Thanks. I think this issue is safe to close then.

@snoyberg snoyberg closed this Jun 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment