Hi Austin,

I see I've completely forgotten to mention that this is on ARM/Linux builder machine so I'm completely out of control of generating build.mk in this case.

Thanks,
Karel

On 03/18/13 11:07 PM, Austin Seipp wrote:
I ran into this earlier today. It's because your build.mk
<http://build.mk> is now out of date; just blow it away and copy the
build.mk.sample file over again and set your BuildFlavour.

However, the stage2 build will later fail because it doesn't think that
LLVM supports -fPIC and -fdynamic on ARM. The patch to fix this is
simple and it will unblock the build, but we'll need to do some work
beyond that - the fallout from using the combo dynamic/static way seems
to have broken some stuff (stage2 no longer builds with LLVM 3.2 for me...)

I will push shortly.



On Mon, Mar 18, 2013 at 3:45 PM, Karel Gardas <[email protected]
<mailto:[email protected]>> wrote:


    Hello Ian,

    am I right assuming that this patch breaks ARM/Linux compilation
    which now fails with:

    ===--- building phase 0
    make -r --no-print-directory -f ghc.mk <http://ghc.mk> phase=0
    phase_0_builds
    ghc.mk:133 <http://ghc.mk:133>: *** dyn is not in $(GhcLibWays), but
    $(DYNAMIC_GHC_PROGRAMS) is YES.  Stop.
    make: *** [all] Error 2

    If so, will you fix this or shall I provide a patch?

    Thanks,
    Karel


    On 03/17/13 01:50 AM, Ian Lynagh wrote:

        Repository : http://darcs.haskell.org/ghc.__git/
        <http://darcs.haskell.org/ghc.git/>

        On branch  : master

        
https://github.com/ghc/ghc/__commit/__b7126674a5f4ead9c73a6a2cbe0fbc__85f7d36c12
        
<https://github.com/ghc/ghc/commit/b7126674a5f4ead9c73a6a2cbe0fbc85f7d36c12>

            ------------------------------__------------------------------__---


        commit b7126674a5f4ead9c73a6a2cbe0fbc__85f7d36c12
        Author: Ian Lynagh<[email protected] <mailto:[email protected]>>
        Date:   Wed Mar 13 21:29:27 2013 +0000

              By default, use the dynamic way for programs in the GHC tree

              In particular, this means that GHCi will use DLLs, rather
        than loading
              object files itself.

           compiler/ghc.mk <http://ghc.mk>             | 10 ++++++++++
           compiler/ghci/Linker.lhs    | 28 +++++++++++-----------------
           compiler/main/DynFlags.hs   |  2 ++
           compiler/utils/Util.lhs     |  9 +--------
        ghc.mk <http://ghc.mk>                      | 12 ++++++------
           mk/build.mk.sample          |  2 +-
           mk/config.mk.in <http://config.mk.in>             |  9 ++++++++-
           mk/validate-settings.mk <http://validate-settings.mk>     |
          4 ++--
           rts/Linker.c                | 14 +++++++-------
           rts/ghc.mk <http://ghc.mk>                  |  4 ++--
           rules/build-package-data.mk <http://build-package-data.mk> |
          2 +-
           rules/build-package-way.mk <http://build-package-way.mk>  |  2 +-
           rules/build-prog.mk <http://build-prog.mk>         |  4 ++--
           rules/shell-wrapper.mk <http://shell-wrapper.mk>      |  4 ++--
           14 files changed, 56 insertions(+), 50 deletions(-)


        Diff suppressed because of size. To see it, use:

              git show b7126674a5f4ead9c73a6a2cbe0fbc__85f7d36c12

        _________________________________________________
        ghc-commits mailing list
        [email protected] <mailto:[email protected]>
        http://www.haskell.org/__mailman/listinfo/ghc-commits
        <http://www.haskell.org/mailman/listinfo/ghc-commits>



    _________________________________________________
    ghc-devs mailing list
    [email protected] <mailto:[email protected]>
    http://www.haskell.org/__mailman/listinfo/ghc-devs
    <http://www.haskell.org/mailman/listinfo/ghc-devs>




--
Regards,
Austin


_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to