Cannot build GHC using the Newcomers guide

older
Problems with `arc` and...

Marius Ghita

26 Jan 2017 26 Jan '17

5:22 a.m.

Following is a list of steps that I ran and their output linked: - clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad62 0b - build.mk configuration https://gist.github.com/mhitza/ 2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a 2c I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/ 6c2b1978ef802707161041abe1d2699e ) -- Google+: https://plus.google.com/111881868112036203454

Attachments:

attachment.html (text/html — 1.9 KB)

Show replies by date

Matthew Pickering

26 Jan 26 Jan

6:05 a.m.

Can you try with the "--no-ghc-package-path" option in your wrapper? Matt On Thu, Jan 26, 2017 at 10:22 AM, Marius Ghita wrote:

...

Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b - build.mk configuration https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I use "export PATH=`stack path --bin-path`" to make the stack installed ghc available in the PATH before building ghc. And that's all. Setting the PATH works better because we do not get any extra env variables set by stack in the environment and we do not go through the stack wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH variable set by the stack command is especially troublesome in some cases. You can try "stack exec env" to check all vars that stack puts in your environment. -harendra On 26 January 2017 at 15:52, Marius Ghita wrote:

...

Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad6 20b - build.mk configuration https://gist.github.com/mhitza /2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181ae f13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266 a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza /6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phyx

12:18 p.m.

Can I ask a silly question. I can't seem to find where stack is recommended for ghc development on the newcomers page, but why is it? I don't want to start another flame war but I can't imagine any scenario where this is useful. As far as I understand the whole benefit of stack is the curated packages. Which are moot here since almost everything you need is in the tree aside from Happy and Alex. Seems to me this is just overcomplicating a very simple process. Not to mention if you have to go through stack - - exec etc all for interactions with the build artifacts it would get old quickly. Also it doesn't seem reliable especially if stack is modifying the environment and or flags passed to the compiler. Let me reiterate, I have nothing against stack, I just don't see the benefits here. Ideally you'd want your environment as simple and vanilla as possible and *totally* in your control IMHO. What am I missing here? Thanks, Tamar On Thu, 26 Jan 2017, 14:21 Harendra Kumar, wrote:

...

I use "export PATH=`stack path --bin-path`" to make the stack installed ghc available in the PATH before building ghc. And that's all.

Setting the PATH works better because we do not get any extra env variables set by stack in the environment and we do not go through the stack wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH variable set by the stack command is especially troublesome in some cases. You can try "stack exec env" to check all vars that stack puts in your environment.

-harendra

On 26 January 2017 at 15:52, Marius Ghita wrote:

Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b - build.mk configuration https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Matthew Pickering

12:28 p.m.

I think the intention is that if you are already using stack to manage your GHC installations then it is desirable to use their managed version of GHC rather than have to install another version. It seems to me that the solution that Harendra suggests is the easiest for anyone with this setup. Fwiw, the easiest way I found to setup a clean development environment for GHC was to use the nix ghcHEAD derviation. nix-shell '<nixpkgs>' -A haskell.compiler.ghcHEAD but of course, this only works if you are using nix! Matt On Thu, Jan 26, 2017 at 5:18 PM, Phyx wrote:

...

Can I ask a silly question. I can't seem to find where stack is recommended for ghc development on the newcomers page, but why is it? I don't want to start another flame war but I can't imagine any scenario where this is useful. As far as I understand the whole benefit of stack is the curated packages.

Which are moot here since almost everything you need is in the tree aside from Happy and Alex. Seems to me this is just overcomplicating a very simple process.

Not to mention if you have to go through stack - - exec etc all for interactions with the build artifacts it would get old quickly. Also it doesn't seem reliable especially if stack is modifying the environment and or flags passed to the compiler.

Let me reiterate, I have nothing against stack, I just don't see the benefits here. Ideally you'd want your environment as simple and vanilla as possible and *totally* in your control IMHO.

What am I missing here?

Thanks, Tamar

On Thu, 26 Jan 2017, 14:21 Harendra Kumar, wrote:

...
I use "export PATH=`stack path --bin-path`" to make the stack installed ghc available in the PATH before building ghc. And that's all.

Setting the PATH works better because we do not get any extra env variables set by stack in the environment and we do not go through the stack wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH variable set by the stack command is especially troublesome in some cases. You can try "stack exec env" to check all vars that stack puts in your environment.

-harendra

On 26 January 2017 at 15:52, Marius Ghita wrote:

...
Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b - build.mk configuration https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phyx

12:38 p.m.

But do you really want to do this? It seems to me you don't want to keep using your stage0 while working on ghc. As you don't want to break it and spend hours wondering why your build failed. Fair enough, if people want to do this. So long as it's not the defacto method. On Thu, 26 Jan 2017, 17:28 Matthew Pickering, wrote:

...

I think the intention is that if you are already using stack to manage your GHC installations then it is desirable to use their managed version of GHC rather than have to install another version.

It seems to me that the solution that Harendra suggests is the easiest for anyone with this setup.

Fwiw, the easiest way I found to setup a clean development environment for GHC was to use the nix ghcHEAD derviation.

nix-shell '<nixpkgs>' -A haskell.compiler.ghcHEAD

but of course, this only works if you are using nix!

Matt

On Thu, Jan 26, 2017 at 5:18 PM, Phyx wrote:

...
Can I ask a silly question. I can't seem to find where stack is recommended for ghc development on the newcomers page, but why is it? I don't want to start another flame war but I can't imagine any scenario where this is useful. As far as I understand the whole benefit of stack is the curated packages.

Which are moot here since almost everything you need is in the tree aside from Happy and Alex. Seems to me this is just overcomplicating a very simple process.

Not to mention if you have to go through stack - - exec etc all for interactions with the build artifacts it would get old quickly. Also it doesn't seem reliable especially if stack is modifying the environment and or flags passed to the compiler.

Let me reiterate, I have nothing against stack, I just don't see the benefits here. Ideally you'd want your environment as simple and vanilla as possible and *totally* in your control IMHO.

What am I missing here?

Thanks, Tamar

On Thu, 26 Jan 2017, 14:21 Harendra Kumar, wrote:

...
I use "export PATH=`stack path --bin-path`" to make the stack installed ghc available in the PATH before building ghc. And that's all.

Setting the PATH works better because we do not get any extra env variables set by stack in the environment and we do not go through the

stack

...
wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH variable set by the stack command is especially troublesome in some cases. You can try "stack exec env" to check all vars that stack puts in your environment.

-harendra

On 26 January 2017 at 15:52, Marius Ghita wrote:

...
Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b - build.mk configuration https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 - boot

https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f

...
- configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Alan & Kim Zimmerman

1:05 p.m.

FWIW, I use the docker image, as per https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#Docker, where I have the invocation in a one-line script Alan On 26 January 2017 at 19:38, Phyx wrote:

...

But do you really want to do this?

It seems to me you don't want to keep using your stage0 while working on ghc. As you don't want to break it and spend hours wondering why your build failed.

Fair enough, if people want to do this. So long as it's not the defacto method.

On Thu, 26 Jan 2017, 17:28 Matthew Pickering, wrote:

...
I think the intention is that if you are already using stack to manage your GHC installations then it is desirable to use their managed version of GHC rather than have to install another version.

It seems to me that the solution that Harendra suggests is the easiest for anyone with this setup.

Fwiw, the easiest way I found to setup a clean development environment for GHC was to use the nix ghcHEAD derviation.

nix-shell '<nixpkgs>' -A haskell.compiler.ghcHEAD

but of course, this only works if you are using nix!

Matt

...
Can I ask a silly question. I can't seem to find where stack is recommended for ghc development on the newcomers page, but why is it? I don't want to start another flame war but I can't imagine any scenario where this is useful. As far as I understand the whole benefit of stack is the curated packages.

Which are moot here since almost everything you need is in the tree

On Thu, Jan 26, 2017 at 5:18 PM, Phyx wrote: aside

...
from Happy and Alex. Seems to me this is just overcomplicating a very simple process.

Not to mention if you have to go through stack - - exec etc all for interactions with the build artifacts it would get old quickly. Also it doesn't seem reliable especially if stack is modifying the environment and or flags passed to the compiler.

Let me reiterate, I have nothing against stack, I just don't see the benefits here. Ideally you'd want your environment as simple and vanilla as possible and *totally* in your control IMHO.

What am I missing here?

Thanks, Tamar

On Thu, 26 Jan 2017, 14:21 Harendra Kumar, wrote:

...
I use "export PATH=`stack path --bin-path`" to make the stack installed ghc available in the PATH before building ghc. And that's all.

Setting the PATH works better because we do not get any extra env variables set by stack in the environment and we do not go through the

stack

...
wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH variable set by the stack command is especially troublesome in some cases. You can try "stack exec env" to check all vars that stack puts in your environment.

-harendra

On 26 January 2017 at 15:52, Marius Ghita wrote:

...
Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b - build.mk configuration https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf

3f

...
- configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Marius Ghita

27 Jan 27 Jan

5:11 a.m.

Thank you all for the feedback, I went with Harendra's solution and that worked fine (and removed any shell wrapping I had to do). To answer Phyx, using stack has become more convenient for managing ghc than using the packages my distro offers (which always falls behind the latest version of GHC by a couple of months), or the alternative of just downloading binaries and managing that process manually. There might also be a misunderstanding given your first post, because I only use stack to provide those ghc (ghc-pkg, alex, happy) binaries, and I'm not managing the ghc source as a stack package; and what that means is that I don't have to run `stack exec --` to interact with build artifacts. On Thu, Jan 26, 2017 at 8:05 PM, Alan & Kim Zimmerman wrote:

...

FWIW, I use the docker image, as per https://ghc.haskell.org/trac/ ghc/wiki/Building/Preparation/Linux#Docker, where I have the invocation in a one-line script

Alan

On 26 January 2017 at 19:38, Phyx wrote:

...
But do you really want to do this?

It seems to me you don't want to keep using your stage0 while working on ghc. As you don't want to break it and spend hours wondering why your build failed.

Fair enough, if people want to do this. So long as it's not the defacto method.

On Thu, 26 Jan 2017, 17:28 Matthew Pickering, < matthewtpickering@gmail.com> wrote:

...
I think the intention is that if you are already using stack to manage your GHC installations then it is desirable to use their managed version of GHC rather than have to install another version.

It seems to me that the solution that Harendra suggests is the easiest for anyone with this setup.

Fwiw, the easiest way I found to setup a clean development environment for GHC was to use the nix ghcHEAD derviation.

nix-shell '<nixpkgs>' -A haskell.compiler.ghcHEAD

but of course, this only works if you are using nix!

Matt

...
Can I ask a silly question. I can't seem to find where stack is recommended for ghc development on the newcomers page, but why is it? I don't want to start another flame war but I can't imagine any scenario where this is useful. As far as I understand the whole benefit of stack is the curated packages.

Which are moot here since almost everything you need is in the tree

...
from Happy and Alex. Seems to me this is just overcomplicating a very simple process.

Not to mention if you have to go through stack - - exec etc all for interactions with the build artifacts it would get old quickly. Also it doesn't seem reliable especially if stack is modifying the environment and or flags passed to the compiler.

Let me reiterate, I have nothing against stack, I just don't see the benefits here. Ideally you'd want your environment as simple and vanilla as possible and *totally* in your control IMHO.

What am I missing here?

Thanks, Tamar

On Thu, 26 Jan 2017, 14:21 Harendra Kumar, wrote:

...
I use "export PATH=`stack path --bin-path`" to make the stack

installed

...
ghc available in the PATH before building ghc. And that's all.

Setting the PATH works better because we do not get any extra env variables set by stack in the environment and we do not go through

On Thu, Jan 26, 2017 at 5:18 PM, Phyx wrote: aside the stack

...
...
wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH variable set by the stack command is especially troublesome in some cases. You can try "stack exec env" to check all vars that stack puts in your environment.

-harendra

On 26 January 2017 at 15:52, Marius Ghita wrote:

...
Following is a list of steps that I ran and their output linked:

- clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b - build.mk configuration https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165b

f3f

...
- configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc from stack (since I don't have a globally installed ghc) (source https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I also have 'ghc-pkg' wrapped in the same way with a stack-ghc-pkg script (source https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )

-- Google+: https://plus.google.com/111881868112036203454

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- Google+: https://plus.google.com/111881868112036203454

3037

Age (days ago)

3038

Last active (days ago)

List overview

Download

7 comments

5 participants

participants (5)

Alan & Kim Zimmerman
Harendra Kumar
Marius Ghita
Matthew Pickering
Phyx