Nested stack exec getting confused

[3noch]

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]

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

[3noch]

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]

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]

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]

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

[3noch]

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

[snoyberg]

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]

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]

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]

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]

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]

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]

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

[snoyberg]

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]

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