Re: Stage1Only
Hi Trevor, That all sounds good to me. By all means go ahead and submit patches, I'll be happy to review them. Cheers, Simon On 24/06/13 19:46, Trevor Elliott wrote: Hi Simon, Sorry about my late response, I haven't had much time to experiment recently. Making with stage=1 causes the rts to never build. Additionally, GHC was failing to build on the master branch with stage=1 when I submitted the patch. So these are just bugs that we should fix. There's no good reason that stage=1 should prevent the RTS from building. I think that Ian has integrated this portion of my original patch. Thanks! My goal was to make it so that generating a cross compiler /only/ was feasible with the build system, as well as allow packages and tools to be disabled for targets where they don't make sense, like the HaLVM. The way things are currently, you'll generate much of the target toolchain in addition to the stage 1 cross compiler. Stage1Only seemed like the documented way to go about this on the wiki, but it seems like nobody feels this should be a supported feature. If there's a valid use case and people want it, it should definitely be a supported feature. I think that the use case here is cross compilation. In order to support a target where you can't run the output of stage1 on the build machine, say cross compilation for ppc from x86, you need to be able to disable certain parts of the build. Iavor and I did an experiment where we tried to use the set of NOT_NEEDED flags to disable everything built with stage2, to simulate the expected functionality of Stage1Only. We had some good success though one hiccup we ran into was that the build system kept looping as a result. I'd be happy to look into this, as I like the level of granularity that the NOT_NEEDED flags give, and think that they're the base functionality that something like Stage1Only should be implemented in terms of. My main concern is to try not to add hacks to the build system to solve very specific problems, but instead think about more general concepts. For example, we're accumulating ways to disable certain subsets of the build - Stage1Only=YES, stage=1, and whatever you need, so probably they should be collected together and should look similar. The way that some bits of functionality are enabled/disabled in build.mk seems like the right place to set up some default settings for the NOT_NEEDED flags. For example, Stage1Only=YES could just expand out to a set of default values for the NOT_NEEDED flags that prevents anything building with the stage2 compiler. This would just give a name to existing functionality, and allow us to remove all other uses of Stage1Only from the build system. I think that accomplishes your goal of not adding any hacks to the build system to solve a specific problem, while still keeping the intent of Stage1Only. We could even pick a different name for Stage1Only after this change, as it should only be used in one place. --trevor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
Hi Simon, Sorry about my late response, I haven't had much time to experiment recently. Making with stage=1 causes the rts to never build. Additionally, GHC was failing to build on the master branch with stage=1 when I submitted the patch. So these are just bugs that we should fix. There's no good reason that stage=1 should prevent the RTS from building. I think that Ian has integrated this portion of my original patch. Thanks! My goal was to make it so that generating a cross compiler /only/ was feasible with the build system, as well as allow packages and tools to be disabled for targets where they don't make sense, like the HaLVM. The way things are currently, you'll generate much of the target toolchain in addition to the stage 1 cross compiler. Stage1Only seemed like the documented way to go about this on the wiki, but it seems like nobody feels this should be a supported feature. If there's a valid use case and people want it, it should definitely be a supported feature. I think that the use case here is cross compilation. In order to support a target where you can't run the output of stage1 on the build machine, say cross compilation for ppc from x86, you need to be able to disable certain parts of the build. Iavor and I did an experiment where we tried to use the set of NOT_NEEDED flags to disable everything built with stage2, to simulate the expected functionality of Stage1Only. We had some good success though one hiccup we ran into was that the build system kept looping as a result. I'd be happy to look into this, as I like the level of granularity that the NOT_NEEDED flags give, and think that they're the base functionality that something like Stage1Only should be implemented in terms of. My main concern is to try not to add hacks to the build system to solve very specific problems, but instead think about more general concepts. For example, we're accumulating ways to disable certain subsets of the build - Stage1Only=YES, stage=1, and whatever you need, so probably they should be collected together and should look similar. The way that some bits of functionality are enabled/disabled in build.mk seems like the right place to set up some default settings for the NOT_NEEDED flags. For example, Stage1Only=YES could just expand out to a set of default values for the NOT_NEEDED flags that prevents anything building with the stage2 compiler. This would just give a name to existing functionality, and allow us to remove all other uses of Stage1Only from the build system. I think that accomplishes your goal of not adding any hacks to the build system to solve a specific problem, while still keeping the intent of Stage1Only. We could even pick a different name for Stage1Only after this change, as it should only be used in one place. --trevor smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On 30 April 2013 19:03, Trevor Elliott wrote: >> I'm a bit confused - what is the issue that you want to "fix"? The fix >> I suggested was to change the name of Stage1Only to more closely reflect >> what it actually does: disable the building of the stage 2 compiler >> *binary* but not the *package*, and install the stage 1 compiler. If >> you additionally want to disable the stage 2 package, you can add >> stage=1 to your build.mk, though the only reason to do that would be to >> speed up the build in cases where you don't need stage 2. > > > Making with stage=1 causes the rts to never build. Additionally, GHC was > failing to build on the master branch with stage=1 when I submitted the > patch. So these are just bugs that we should fix. There's no good reason that stage=1 should prevent the RTS from building. > My goal was to make it so that generating a cross compiler /only/ was > feasible with the build system, as well as allow packages and tools to be > disabled for targets where they don't make sense, like the HaLVM. The way > things are currently, you'll generate much of the target toolchain in > addition to the stage 1 cross compiler. Stage1Only seemed like the > documented way to go about this on the wiki, but it seems like nobody feels > this should be a supported feature. If there's a valid use case and people want it, it should definitely be a supported feature. My main concern is to try not to add hacks to the build system to solve very specific problems, but instead think about more general concepts. For example, we're accumulating ways to disable certain subsets of the build - Stage1Only=YES, stage=1, and whatever you need, so probably they should be collected together and should look similar. Cheers, Simon > I'd really like to see something in the spirit of Stage1Only, and > package/tool disabling working, as it would allow us to more closely > integrate the HaLVM with the ghc build system. I'm very much willing to do > the work if you and Ian can give me some pointers for how you'd like it > done. > > --trevor > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
I'm a bit confused - what is the issue that you want to "fix"? The fix I suggested was to change the name of Stage1Only to more closely reflect what it actually does: disable the building of the stage 2 compiler *binary* but not the *package*, and install the stage 1 compiler. If you additionally want to disable the stage 2 package, you can add stage=1 to your build.mk, though the only reason to do that would be to speed up the build in cases where you don't need stage 2. Making with stage=1 causes the rts to never build. Additionally, GHC was failing to build on the master branch with stage=1 when I submitted the patch. My goal was to make it so that generating a cross compiler /only/ was feasible with the build system, as well as allow packages and tools to be disabled for targets where they don't make sense, like the HaLVM. The way things are currently, you'll generate much of the target toolchain in addition to the stage 1 cross compiler. Stage1Only seemed like the documented way to go about this on the wiki, but it seems like nobody feels this should be a supported feature. I'd really like to see something in the spirit of Stage1Only, and package/tool disabling working, as it would allow us to more closely integrate the HaLVM with the ghc build system. I'm very much willing to do the work if you and Ian can give me some pointers for how you'd like it done. --trevor smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On 15/04/13 22:25, Trevor Elliott wrote: In retrospect I should have used a different name. Feel free to fix it (and the wiki page). I've created a ticket with a patch that I think addresses this issue [1]. The patch adds a mechanism that allows packages and programs to be disabled when building with a specific stage of GHC. It also adds a default set of disabled packages when Stage1Only is set. I'm a bit confused - what is the issue that you want to "fix"? The fix I suggested was to change the name of Stage1Only to more closely reflect what it actually does: disable the building of the stage 2 compiler *binary* but not the *package*, and install the stage 1 compiler. If you additionally want to disable the stage 2 package, you can add stage=1 to your build.mk, though the only reason to do that would be to speed up the build in cases where you don't need stage 2. What is it that actually goes wrong for you? Cheers, Simon A side effect of this change is that no package adds an RTS dependency when Stage1Only is enabled, so I've also added all_rts to the all target in rts/ghc.mk. I wasn't able to figure out where the dependency on the all_rts target comes from, so if that change doesn't make sense I'm happy to modify the attached patch :) --trevor [1] http://hackage.haskell.org/trac/ghc/ticket/7841 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] Stage1Only only builds stage 1
Hi Everyone, I created a ticket that includes some changes to allow the Stage1Only flag to only build stage 1. This makes it easier to build cross compilers where the target won't be a suitable environment to actually host a stage 2 compiler. http://hackage.haskell.org/trac/ghc/ticket/7841 Thanks! --trevor smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
In retrospect I should have used a different name. Feel free to fix it (and the wiki page). I've created a ticket with a patch that I think addresses this issue [1]. The patch adds a mechanism that allows packages and programs to be disabled when building with a specific stage of GHC. It also adds a default set of disabled packages when Stage1Only is set. A side effect of this change is that no package adds an RTS dependency when Stage1Only is enabled, so I've also added all_rts to the all target in rts/ghc.mk. I wasn't able to figure out where the dependency on the all_rts target comes from, so if that change doesn't make sense I'm happy to modify the attached patch :) --trevor [1] http://hackage.haskell.org/trac/ghc/ticket/7841 smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On 12/04/13 05:51, Gabor Greif wrote: On 4/9/13, Gabor Greif wrote: On 4/9/13, Trevor Elliott wrote: So this did something different, but still tries to build tools like hsc2hs with the stage1 compiler. This won't really work for a target like the HaLVM, as there's no notion of a filesystem in the target environment. I made the same observation. In cross-mode with Stage1Only many (if not all) of the compiler/ lib is built, but there is no final linking of stage2. Following up on this... The relevant excerpt from the make --debug log seems to be Successfully remade target file `all_compiler_stage1'. File `all_compiler' does not exist. File `all_compiler_stage2' does not exist. File `all_compiler_stage2_v' does not exist. File `compiler/stage2/build/libHSghc-7.7.20130407.a' does not exist. Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)=="YES". Let's see if I can fix it. http://www.quickmeme.com/meme/3twwox/ Setting Stage1Only=YES says "build the stage 1 compiler and all of the packages". Guess what? Stage 2 is one of the packages. :-) In retrospect I should have used a different name. Feel free to fix it (and the wiki page). Cheers, Simon Cheers, Gabor Gabor So, back to my original question: what's the easiest way to just generate a stage1 compiler and the libraries that it will require? Thanks! --trevor On 04/08/2013 06:07 PM, Trevor Elliott wrote: I searched on trac for bugs relating to Stage1Only, and didn't come up with anything, but a google search turned up this: http://hackage.haskell.org/trac/ghc/ticket/7639 I'm going to try passing stage=1 in build.mk. --trevor On 04/08/2013 05:20 PM, Trevor Elliott wrote: Hi Everyone, I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools. What is the best way to stop the build system after stage1 + libraries has finished? Thanks! --trevor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On 4/12/13, Trevor Elliott wrote: > Hi Ian, > > I've seen this ticket (see [1]), and stage=1 only worked if I explicitly > disabled building packages like ghc, and the tools with the stage 1 > compiler. This seemed reasonable, as I only wanted to build a cross > compiler, not a toolchain for my target. My preliminary experience is that cabal fails (somewhere) because it cannot locate the 'ghc' package. So I've built without "stage=1" first, and after cabal did its thing (and the 'relocation out of range' error stopped my build) I re-issued a make with "stage=1". This brought me till the already known dyn problem with integer-simple. Cheers, Gabor > > Additionally, I found that the RTS would never get built as a dependency > for ghc-prim when using stage=1. The ghc-prim package only builds > dist-boot and dist-install variants, and the RTS only ever builds a dist > variant. When dependencies are generated in build-package-way for > ghc-prim, the variable rts-1.0_dist-install_$(way)_LIB expands to "", > and ghc-prim builds without forcing the RTS to also build. > > I've fixed this by adding a dist-install alias (listed below) in > rts/ghc.mk, as well as adding $$($1_$2_$3_DEPS_LIBS) to the dependencies > of the static archive rule in rules/build-package-way.mk. > > > rts-$(rts_VERSION)_dist-install_$1_LIB = $$(rts_$1_LIB) > > I have some other changes that make Stage1Only work as expected, and > would be happy to submit a patch if it's desired functionality. > > Thanks! > > --trevor > > [1] http://www.haskell.org/pipermail/ghc-devs/2013-April/001002.html > > On Fri 12 Apr 2013 05:58:40 AM PDT, Ian Lynagh wrote: >> On Fri, Apr 12, 2013 at 02:51:44PM +0200, Gabor Greif wrote: >>> >>> Apparently all_compiler depends on all_compiler_stage2 currently, >>> which it should not, given $(Stage1Only)=="YES". >> >> See http://hackage.haskell.org/trac/ghc/ticket/7639#comment:5 >> >> >> Thanks >> Ian >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
Hi Ian, I've seen this ticket (see [1]), and stage=1 only worked if I explicitly disabled building packages like ghc, and the tools with the stage 1 compiler. This seemed reasonable, as I only wanted to build a cross compiler, not a toolchain for my target. Additionally, I found that the RTS would never get built as a dependency for ghc-prim when using stage=1. The ghc-prim package only builds dist-boot and dist-install variants, and the RTS only ever builds a dist variant. When dependencies are generated in build-package-way for ghc-prim, the variable rts-1.0_dist-install_$(way)_LIB expands to "", and ghc-prim builds without forcing the RTS to also build. I've fixed this by adding a dist-install alias (listed below) in rts/ghc.mk, as well as adding $$($1_$2_$3_DEPS_LIBS) to the dependencies of the static archive rule in rules/build-package-way.mk. > rts-$(rts_VERSION)_dist-install_$1_LIB = $$(rts_$1_LIB) I have some other changes that make Stage1Only work as expected, and would be happy to submit a patch if it's desired functionality. Thanks! --trevor [1] http://www.haskell.org/pipermail/ghc-devs/2013-April/001002.html On Fri 12 Apr 2013 05:58:40 AM PDT, Ian Lynagh wrote: On Fri, Apr 12, 2013 at 02:51:44PM +0200, Gabor Greif wrote: Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)=="YES". See http://hackage.haskell.org/trac/ghc/ticket/7639#comment:5 Thanks Ian smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On Fri, Apr 12, 2013 at 02:51:44PM +0200, Gabor Greif wrote: > > Apparently all_compiler depends on all_compiler_stage2 currently, > which it should not, given $(Stage1Only)=="YES". See http://hackage.haskell.org/trac/ghc/ticket/7639#comment:5 Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On 4/9/13, Gabor Greif wrote: > On 4/9/13, Trevor Elliott wrote: >> So this did something different, but still tries to build tools like >> hsc2hs with the stage1 compiler. This won't really work for a target >> like the HaLVM, as there's no notion of a filesystem in the target >> environment. > > I made the same observation. In cross-mode with Stage1Only many (if > not all) of the compiler/ lib is built, but there is no final linking > of stage2. Following up on this... The relevant excerpt from the make --debug log seems to be Successfully remade target file `all_compiler_stage1'. File `all_compiler' does not exist. File `all_compiler_stage2' does not exist. File `all_compiler_stage2_v' does not exist. File `compiler/stage2/build/libHSghc-7.7.20130407.a' does not exist. Apparently all_compiler depends on all_compiler_stage2 currently, which it should not, given $(Stage1Only)=="YES". Let's see if I can fix it. Cheers, Gabor > > Gabor > >> >> So, back to my original question: what's the easiest way to just >> generate a stage1 compiler and the libraries that it will require? >> >> Thanks! >> >> --trevor >> >> On 04/08/2013 06:07 PM, Trevor Elliott wrote: >>> I searched on trac for bugs relating to Stage1Only, and didn't come up >>> with anything, but a google search turned up this: >>> >>> http://hackage.haskell.org/trac/ghc/ticket/7639 >>> >>> I'm going to try passing stage=1 in build.mk. >>> >>> --trevor >>> >>> On 04/08/2013 05:20 PM, Trevor Elliott wrote: >>>> Hi Everyone, >>>> >>>> I've been trying to produce just a stage1 compiler by setting >>>> Stage1Only >>>> in my mk/build.mk. What I've been discovering, is that the build >>>> system >>>> seems to ignore this (or I haven't set it in the right place) and trys >>>> to build a stage2 compiler and its associated tools. >>>> >>>> What is the best way to stop the build system after stage1 + libraries >>>> has finished? >>>> >>>> Thanks! >>>> >>>> --trevor >>>> >>>> >>>> >>>> ___ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> >>> >>> >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
On 4/9/13, Trevor Elliott wrote: > So this did something different, but still tries to build tools like > hsc2hs with the stage1 compiler. This won't really work for a target > like the HaLVM, as there's no notion of a filesystem in the target > environment. I made the same observation. In cross-mode with Stage1Only many (if not all) of the compiler/ lib is built, but there is no final linking of stage2. Gabor > > So, back to my original question: what's the easiest way to just > generate a stage1 compiler and the libraries that it will require? > > Thanks! > > --trevor > > On 04/08/2013 06:07 PM, Trevor Elliott wrote: >> I searched on trac for bugs relating to Stage1Only, and didn't come up >> with anything, but a google search turned up this: >> >> http://hackage.haskell.org/trac/ghc/ticket/7639 >> >> I'm going to try passing stage=1 in build.mk. >> >> --trevor >> >> On 04/08/2013 05:20 PM, Trevor Elliott wrote: >>> Hi Everyone, >>> >>> I've been trying to produce just a stage1 compiler by setting Stage1Only >>> in my mk/build.mk. What I've been discovering, is that the build system >>> seems to ignore this (or I haven't set it in the right place) and trys >>> to build a stage2 compiler and its associated tools. >>> >>> What is the best way to stop the build system after stage1 + libraries >>> has finished? >>> >>> Thanks! >>> >>> --trevor >>> >>> >>> >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
So this did something different, but still tries to build tools like hsc2hs with the stage1 compiler. This won't really work for a target like the HaLVM, as there's no notion of a filesystem in the target environment. So, back to my original question: what's the easiest way to just generate a stage1 compiler and the libraries that it will require? Thanks! --trevor On 04/08/2013 06:07 PM, Trevor Elliott wrote: I searched on trac for bugs relating to Stage1Only, and didn't come up with anything, but a google search turned up this: http://hackage.haskell.org/trac/ghc/ticket/7639 I'm going to try passing stage=1 in build.mk. --trevor On 04/08/2013 05:20 PM, Trevor Elliott wrote: Hi Everyone, I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools. What is the best way to stop the build system after stage1 + libraries has finished? Thanks! --trevor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Stage1Only
I searched on trac for bugs relating to Stage1Only, and didn't come up with anything, but a google search turned up this: http://hackage.haskell.org/trac/ghc/ticket/7639 I'm going to try passing stage=1 in build.mk. --trevor On 04/08/2013 05:20 PM, Trevor Elliott wrote: Hi Everyone, I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools. What is the best way to stop the build system after stage1 + libraries has finished? Thanks! --trevor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Stage1Only
Hi Everyone, I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools. What is the best way to stop the build system after stage1 + libraries has finished? Thanks! --trevor smime.p7s Description: S/MIME Cryptographic Signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[a pile of random patches] Re: Stage1Only=YES does not seem to work on current master
On Tue, 29 Jan 2013 10:20:19 + Simon Marlow wrote: > On 27/01/13 21:21, Sergei Trofimovich wrote: > > simple build.mk: > > > > SRC_CC_OPTS+=-O2 -pipe > > > > BUILD_DOCBOOK_PDF = NO > > BUILD_DOCBOOK_PS = NO > > BUILD_DOCBOOK_HTML = NO > > HADDOCK_DOCS = NO > > SRC_HC_OPTS+=-w > > > > Stage1Only=YES > > GhcUnregisterised=YES > > SplitObjs=NO > > > > Leads to failures of missing stage2: > > > > "inplace/lib/unlit" utils/count_lines/count_lines.lprl > > utils/count_lines/dist/count_lines.prl > > "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe > > -optc-Ilibraries/primitive/cbits > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' > > -static -H32m -O -w-package-name primitive-0.4.0.1 > > -hide-all-packages -i -ilibraries/primitive/. > > -ilibraries/primitive/dist-install/build > > -ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/dist-install/build > > -Ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/cbits-optP-include > > -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package > > base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 > > -no-user-package-db -rtsopts -c libraries/prim > itive/cbits/primitive-memops.c -o > libraries/primitive/dist-install/build/cbits/primitive-memops.o > > "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe > > -optc-Ilibraries/primitive/cbits > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' > > -static -prof -H32m -O -w-package-name primitive-0.4.0.1 > > -hide-all-packages -i -ilibraries/primitive/. > > -ilibraries/primitive/dist-install/build > > -ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/dist-install/build > > -Ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/cbits-optP-include > > -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package > > base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 > > -no-user-package-db -rtsopts -c librarie > s/primitive/cbits/primitive-memops.c -o > libraries/primitive/dist-install/build/cbits/primitive-memops.p_o > > /bin/sh: inplace/bin/ghc-stage2: No such file or directory > > make[1]: *** > > [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 127 > > make[1]: *** Waiting for unfinished jobs > > /bin/sh: inplace/bin/ghc-stage2: No such file or directory > > I just pushed a patch that should fix this. Part of the problem is that > the --no-dph flag to sync-all doesn't disable the primitive & vector > repos like it used to, because they are now submodules. I've fixed it > in the build system instead. Yeah, your change fixed 'make' for stage1only. make install does not work though (and didn't before): $ make install DESTDIR=/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image/ ... Installing library in /var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image/usr/lib64/ghc-7.7.20130129/bin-package-db-0.0.0.0 CROSS_COMPILE="ia64-unknown-linux-gnu-" "inplace/bin/ghc-cabal" copy "strip" libraries/hoopl dist-install '/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image' '/usr' '/usr/lib64/ghc-7.7.20130129' '/usr/share/doc/ghc-/html/libraries' Installing library in /var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image/usr/lib64/ghc-7.7.20130129/hoopl-3.10.0.0 CROSS_COMPILE="ia64-unknown-linux-gnu-" "inplace/bin/ghc-cabal" copy "strip" libraries/transformers dist-install '/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image' '/usr' '/usr/l
Re: Stage1Only=YES does not seem to work on current master
On 27/01/13 21:21, Sergei Trofimovich wrote: simple build.mk: SRC_CC_OPTS+=-O2 -pipe BUILD_DOCBOOK_PDF = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_HTML = NO HADDOCK_DOCS = NO SRC_HC_OPTS+=-w Stage1Only=YES GhcUnregisterised=YES SplitObjs=NO Leads to failures of missing stage2: "inplace/lib/unlit" utils/count_lines/count_lines.lprl utils/count_lines/dist/count_lines.prl "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe -optc-Ilibraries/primitive/cbits -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' -static -H32m -O -w-package-name primitive-0.4.0.1 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -c libraries/prim itive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.o "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe -optc-Ilibraries/primitive/cbits -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' -static -prof -H32m -O -w-package-name primitive-0.4.0.1 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -c librarie s/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.p_o /bin/sh: inplace/bin/ghc-stage2: No such file or directory make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 127 make[1]: *** Waiting for unfinished jobs /bin/sh: inplace/bin/ghc-stage2: No such file or directory I just pushed a patch that should fix this. Part of the problem is that the --no-dph flag to sync-all doesn't disable the primitive & vector repos like it used to, because they are now submodules. I've fixed it in the build system instead. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Stage1Only=YES does not seem to work on current master
simple build.mk: SRC_CC_OPTS+=-O2 -pipe BUILD_DOCBOOK_PDF = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_HTML = NO HADDOCK_DOCS = NO SRC_HC_OPTS+=-w Stage1Only=YES GhcUnregisterised=YES SplitObjs=NO Leads to failures of missing stage2: "inplace/lib/unlit" utils/count_lines/count_lines.lprl utils/count_lines/dist/count_lines.prl "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe -optc-Ilibraries/primitive/cbits -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' -static -H32m -O -w-package-name primitive-0.4.0.1 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.o "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe -optc-Ilibraries/primitive/cbits -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' -static -prof -H32m -O -w-package-name primitive-0.4.0.1 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.p_o /bin/sh: inplace/bin/ghc-stage2: No such file or directory make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 127 make[1]: *** Waiting for unfinished jobs /bin/sh: inplace/bin/ghc-stage2: No such file or directory -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
