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

Nested stack exec getting confused #420

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

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@3noch

This comment has been minimized.

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

This comment has been minimized.

Contributor

DanBurton commented Jun 26, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@3noch

This comment has been minimized.

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

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@3noch

This comment has been minimized.

Member

3noch commented Jun 26, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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

This comment has been minimized.

Member

3noch commented Jun 26, 2015

Done.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

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