any successfull ghc registerised builds on arm?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

any successfull ghc registerised builds on arm?

Nathan Hüsken
In a different thread (Error building ghc on raspberry pi):

On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
>
> I did eventually finish building stage2, but the final executable
segfaulted on start.
> I haven't investigated much why that happened, the days it takes to
rebuild it just
> made me give up.

Was that an registerised or unregisterised build?
Did anyone succesfully build ghc on an arm system which produces non
crashing executables?

I am asking, because I build a arm-linux-androideabi cross compiler, but
the executables crash.
Only in an unregisterised build, they work.

So I wonder if it is a general arm problem or has to do with android.

Thanks!
Nathan

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

stefan kersten-2
hi nathan,

On Jan 14, 2013, at 6:15 PM, Nathan Hüsken <[hidden email]> wrote:
> Did anyone succesfully build ghc on an arm system which produces non
> crashing executables?
>
> I am asking, because I build a arm-linux-androideabi cross compiler, but
> the executables crash.
> Only in an unregisterised build, they work.
>
> So I wonder if it is a general arm problem or has to do with android.

stephen blackheath's ghc port to iOS cross compiles to armv7 [1] (using llvm, registerised, i assume?). see [2] for a list of libraries i've built and run on iOS. here [3] is some info on cross compiling for blackberry arm (QNX). maybe it would be worthwhile asking on the iphone mailing list [4], too?

sk

[1] https://github.com/ghc-ios/ghc/wiki
[2] https://github.com/kaoskorobase/ghc-ios-cabal-scripts
[3] http://www.haskell.org/pipermail/iphone/2012-November/000142.html
[4] http://www.haskell.org/mailman/listinfo/iphone


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Karel Gardas
In reply to this post by Nathan Hüsken
On 01/14/13 06:15 PM, Nathan Hüsken wrote:

> In a different thread (Error building ghc on raspberry pi):
>
> On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
>>
>> I did eventually finish building stage2, but the final executable
> segfaulted on start.
>> I haven't investigated much why that happened, the days it takes to
> rebuild it just
>> made me give up.
>
> Was that an registerised or unregisterised build?
> Did anyone succesfully build ghc on an arm system which produces non
> crashing executables?
>
> I am asking, because I build a arm-linux-androideabi cross compiler, but
> the executables crash.
> Only in an unregisterised build, they work.
>
> So I wonder if it is a general arm problem or has to do with android.

I'm going to resurrect my pandaboard and build GHC HEAD hopefully this
or next night. Also I plan resurrect ARM builder on i.MX53 QSB sometimes
at the end of this month.

Cheers,
Karel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Austin Seipp
In reply to this post by Nathan Hüsken
(CC'ing glasgow-haskell-users, as it got lost somehow. A message or
two from me and Karel are also missing the list.)

On Mon, Jan 14, 2013 at 1:27 PM, Ben Gamari <[hidden email]> wrote:

> Austin Seipp <[hidden email]> writes:
>
>> I've been working on ARM the past weekend. Here's where I'm at
>> (semi-long email ahead.)
>>
> I've also been working on this slowly over the last few weeks (in all of
> the discussion below, I'm building for a Pandaboard with Ubuntu's ghc
> 7.4 package). Unfortunately, most of my efforts have been going into
> convincing llc and gcc to build compatible objects. With GHC 7.6 simply
> taking the brute force approach with SRC_HC_OPTS seems to work,
>
>     SRC_HC_OPTS        = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-mcpu=cortex-a9 # -optlc-float-abi=hard
>
> With this, I can produce a compiler and run the testsuite to generate
> this not-entirely-depressing picture,
>
>     OVERALL SUMMARY for test run started at Sat Jan  5 17:12:12 UTC 2013
>         3400 total tests, which gave rise to
>         8322 test cases, of which
>            4 caused framework failures
>         5311 were skipped
>
>         2649 expected passes
>           47 had missing libraries
>           59 expected failures
>            0 unexpected passes
>          252 unexpected failures
>
> Sadly a good portion of the failures seem to be due to ghci crashing due
> to either a segmentation fault or illegal instruction.
> This is likely due to linker support needing either to be written or
> fixed. I'll have to brush off my linker knowledge and have a look at
> these (probably next weekend).

Yes, the linker bit was one of the components of the stage2 compiler
worrying me the most, especially since in our past conversations,
we've both seen it segfault when linking libraries while building
things like vector. I really can't wait for a future where GHC on
Linux supports dynamic by default out of the box (and ARM should fit
in this category, too.)

> In my opinion it's worth having a released compiler built as a refernce. The
> ghc-7.6 branch is pretty easy to get going if you ever have some spare
> CPU cycles available.

Spare cycles do occur sometimes, so I'll give a shot to building it
with LLVM-3.0 later when I get the chance.

>> Overall I think squashing as many bugs as possible in HEAD is the
>> correct route at the moment. This is only my opinion. My plans are to
>> get a working stage1 registered GHC HEAD, and begin running the
>> testsuite against it, filing down bugs. Eventually, this should lead
>> to a stage2 as we narrow things down.
>>
> Is this to say that you've been unable to successfully build a stage 2
> compiler? I'm currently in the middle of a build of HEAD. We'll see how
> far this makes it.

Yes, on my ODROID I have yet to build a stage2 compiler. This is
mostly due to bugs in the LLVM backend in combination with the new
code generator, it seems. I get through the entire stage1 build and
the build of several of the libraries, but now I'm stuck compiling
base with stage1. This is the bug I have yet to fix, in this area:

http://hackage.haskell.org/trac/ghc/ticket/7575

I speculate the cause of this bug is eerily similar to the other two
bugs I fixed relating to properly narrowing/widening LLVM variable
types. Take a look at these bugs and their patches:

http://hackage.haskell.org/trac/ghc/ticket/7571
http://hackage.haskell.org/trac/ghc/ticket/7580

so I imagine I can get this fixed tonight and move on.

> Out of curiosity, what are the build times on the ODROID?

I haven't completed a full build so it's hard to estimate. But with a
quick build and 'make -j4', the build seems to chug along fairly
respectably, and I'd say I can get through the entire stage1 compiler
build in the ballpark of ~30ish minutes. This is a very rough estimate
because with enough parallelism, it's hard to see "how far" you are in
the build, obviously. At a guess, I speculate a full build of
everything at -j4 would be somewhere on the order of an hour and a
half, to two-plus hours.

> I agree that having nightly buildbots would be very nice. I meant to
> setup my PandaBoard in this capacity after finishing my linker work, but
> sadly life and hardware failures got in the way.

Yes, PandaBoards aren't the most reliable as several of us seem to
realize. :) Anything you could contribute here would be wonderful. I'm
new to the buildbot infrastructure, so when the "time is right" I'll
rally people about this again.

> Very true. It would be very nice if we could handle this issue
> automatically after we figure out the proper way to handle it manually.

I think Karel is right that we may be able to get 90% of the way there
with a short hack in DriverPipeline, with some ./configure logic to
fix it, but easier said than done, I'm sure (abusrdly long build times
don't help I bet.)

> To be fair, hacking on the compiler itself is a bit sexier than hacking
> on the build system.

There are also considerably fewer variables named things like '$$$$$'
and '@$$$$' in the compiler than build system, which certainly helps
*me*, at least. :)

> Historically I've written up my experience on my own nearly non-existent
> blog[1][2][3]. Given the vanishingly small probability that someone will
> actually find this information, I think I'll start trying to put
> together a page on the Wiki instead. I agree that having a centralized
> location to place this sort of information is extremely valuable. A good
> portion of the effort in starting a project like this is determining
> what others have done.
>
> There already exists a ArmLinuxGhc[4] page on the wiki. That being said,
> it's woefully out of date and much of the discussion centers around
> other Haskell implementations. I'd say it would be fair to start with a
> clean slate on this page and describe the current state of things, the
> ideosyncracies of building GHC on ARM (e.g. float ABI issues), and what
> remains to be done (a list of failing tests when the reason for failure
> is known might be useful).
>
> Cheers,
>
> - Ben

Agreed. I'll look into cleaning up the wiki page later with a good
outline, so hopefully more users can contribute.

>
> [1] http://bgamari.github.com/posts/2013-01-04-ghc-arm-update.html
> [2] http://bgamari.github.com/posts/2012-01-27-ghc-llvm-arm.html
> [3] http://bgamari.github.com/posts/2011-10-17-crosscompiling_llvm.html
> [4] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc



--
Regards,
Austin

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Karel Gardas
On 01/14/13 08:49 PM, Austin Seipp wrote:
>> Very true. It would be very nice if we could handle this issue
>> automatically after we figure out the proper way to handle it manually.
>
> I think Karel is right that we may be able to get 90% of the way there
> with a short hack in DriverPipeline, with some ./configure logic to
> fix it, but easier said than done, I'm sure (abusrdly long build times
> don't help I bet.)

What I'm talking about is aclocal.m4 GET_ARM_ISA function. There we need
to check for ARMv6's VFP implementation and set ARM_ISA_EXT accordingly.
I don't have Rasberry here so I'm not sure how to check for VFP versus
VFPv2 in a best way, but probably we may omit this and just assume when
we do have ARMv6 the VFP is v2? Once this is done, then just
DriverPipeline.hs need to check for this and set appropriate vfpv2
option for llc...

Karel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
In reply to this post by Nathan Hüsken
Somebody claiming to be Nathan Hüsken wrote:
>Was that an registerised or unregisterised build?
>Did anyone succesfully build ghc on an arm system which produces non
>crashing executables?

Just finally got a BB10 device set up so I can test my cross-compiler on the
ARM and I get:

Process 26726597 (Main) terminated SIGSEGV code=2 fltno=11
ip=08bbf4c0(/accounts/1000/appdata/net.singpolyma.haskades_headlines.testDev_s_headlinesc1f463d0/app/native/Main@MD5Update+0xcc8d7)
ref=e59d0040
Memory fault (core dumped)

This seems related.  I'm about to try a configuration with
--enable-unregisterised to see if that helps.

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
Somebody claiming to be Stephen Paul Weber wrote:

>Somebody claiming to be Nathan Hüsken wrote:
>>Was that an registerised or unregisterised build?
>>Did anyone succesfully build ghc on an arm system which produces non
>>crashing executables?
>
>Just finally got a BB10 device set up so I can test my cross-compiler on
>the ARM
>
>I'm about to try a configuration with --enable-unregisterised to see if
>that helps.

make -r --no-print-directory -f ghc.mk phase=final all
"inplace/bin/ghc-stage1" -static  -H64m -O0 -fasm    -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/.    -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0  -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fasm  -no-user-package-db -rtsopts      -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o

when making flags consistent: Warning:
     Compiler unregisterised, so compiling via C
/tmp/ghc25891_0/ghc25891_0.hc: In function 'c2pA_entry':

/tmp/ghc25891_0/ghc25891_0.hc:3691:1:
      warning: this decimal constant is unsigned only in ISO C90 [enabled by default]

/tmp/ghc25891_0/ghc25891_0.hc:3691:17:
      error: expected ')' before numeric constant
make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1
make: *** [all] Error 2

I think I can configure it to use unregistered LLVM, so I'm off to try that,
but this seems like a bug.

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
Somebody claiming to be Stephen Paul Weber wrote:

>Somebody claiming to be Stephen Paul Weber wrote:
>>Somebody claiming to be Nathan Hüsken wrote:
>>>Was that an registerised or unregisterised build?
>>>Did anyone succesfully build ghc on an arm system which produces non
>>>crashing executables?
>>
>>Just finally got a BB10 device set up so I can test my
>>cross-compiler on the ARM
>>
>>I'm about to try a configuration with --enable-unregisterised to
>>see if that helps.
>
>I think I can configure it to use unregistered LLVM, so I'm off to
>try that, but this seems like a bug.

Trying that gives me:

[ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o )
Warning: Couldn't figure out LLVM version!
          Make sure you have installed LLVM
ghc: could not execute: opt-3.0
make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1
make: *** [all] Error 2

I'm using LLVM 3.1.  This errors makes no sense to me, because when I just use "quick" and not unregistered, it falls back to LLVM and works fine, but now I've selected "quick-llvm" and unregistered and it can't find it?

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Nathan Hüsken
I got this error too.
In my case it helped to install llvm-3.0 next to llvm (in ubuntu the
executables are than called llc-3.0 and opt-3.0).

I believe this error just came in the first phase, and was caused by the
preinstalled ghc-7.4.2.
But I am not sure.

On 01/19/2013 07:45 AM, Stephen Paul Weber wrote:

> Somebody claiming to be Stephen Paul Weber wrote:
>> Somebody claiming to be Stephen Paul Weber wrote:
>>> Somebody claiming to be Nathan Hüsken wrote:
>>>> Was that an registerised or unregisterised build?
>>>> Did anyone succesfully build ghc on an arm system which produces non
>>>> crashing executables?
>>>
>>> Just finally got a BB10 device set up so I can test my cross-compiler
>>> on the ARM
>>>
>>> I'm about to try a configuration with --enable-unregisterised to see
>>> if that helps.
>>
>> I think I can configure it to use unregistered LLVM, so I'm off to try
>> that, but this seems like a bug.
>
> Trying that gives me:
>
> [ 1 of 68] Compiling Distribution.Compat.Exception (
> libraries/Cabal/Cabal/Distribution/Compat/Exception.hs,
> bootstrapping/Distribution/Compat/Exception.o )
> Warning: Couldn't figure out LLVM version!
>          Make sure you have installed LLVM
> ghc: could not execute: opt-3.0
> make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1
> make: *** [all] Error 2
>
> I'm using LLVM 3.1.  This errors makes no sense to me, because when I
> just use "quick" and not unregistered, it falls back to LLVM and works
> fine, but now I've selected "quick-llvm" and unregistered and it can't
> find it?
>


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Ben Gamari
In reply to this post by Stephen Paul Weber
Stephen Paul Weber <[hidden email]> writes:

> Trying that gives me:
>
> [ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o )
> Warning: Couldn't figure out LLVM version!
>           Make sure you have installed LLVM
> ghc: could not execute: opt-3.0
> make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1
> make: *** [all] Error 2
>
> I'm using LLVM 3.1.  This errors makes no sense to me, because when I
> just use "quick" and not unregistered, it falls back to LLVM and works
> fine, but now I've selected "quick-llvm" and unregistered and it can't
> find it?
>
Are you certain the opt-3.0 is in $PATH? Perhaps verify this by `which opt-3.0`.

Cheers,

- Ben

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
Somebody claiming to be Ben Gamari wrote:

>Stephen Paul Weber <[hidden email]> writes:
>> Trying that gives me:
>>
>> Warning: Couldn't figure out LLVM version!
>>           Make sure you have installed LLVM
>> ghc: could not execute: opt-3.0
>>
>> I'm using LLVM 3.1.
>>
>Are you certain the opt-3.0 is in $PATH?

It isn't installed.  I'm using LLVM 3.1, and GHC correctly uses opt-3.1 when
I try the registered build.

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Karel Gardas

Hi,

I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float
ABI distro. I used distro provided LLVM 3.0 and configured GHC with:

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

And resulting ghc-stage2 is not only able to complete the build but also
builds HelloWorld example which runs fine:

$ ./inplace/bin/ghc-stage2 --info
  [("Project name","The Glorious Glasgow Haskell Compilation System")
  ,("GCC extra via C opts"," -fwrapv")
  ,("C compiler command","/usr/bin/gcc")
  ,("C compiler flags"," -fno-stack-protector  -Wl,--hash-size=31
-Wl,--reduce-memory-overheads")
  ,("ar command","/usr/bin/ar")
  ,("ar flags","q")
  ,("ar supports at file","YES")
  ,("touch command","touch")
  ,("dllwrap command","/bin/false")
  ,("windres command","/bin/false")
  ,("perl command","/usr/bin/perl")
  ,("target os","OSLinux")
  ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON],
armABI = HARD}")
  ,("target word size","4")
  ,("target has GNU nonexec stack","False")
  ,("target has .ident directive","True")
  ,("target has subsections via symbols","False")
  ,("LLVM llc command","/usr/bin/llc-3.0")
  ,("LLVM opt command","/usr/bin/opt-3.0")
  ,("Project version","7.6.1")
  ,("Booter version","7.4.1")
  ,("Stage","2")
  ,("Build platform","arm-unknown-linux")
  ,("Host platform","arm-unknown-linux")
  ,("Target platform","arm-unknown-linux")
  ,("Have interpreter","YES")
  ,("Object splitting supported","NO")
  ,("Have native code generator","NO")
  ,("Support SMP","YES")
  ,("Unregisterised","NO")
  ,("Tables next to code","YES")
  ,("RTS ways","l debug  thr thr_debug thr_l thr_p ")
  ,("Leading underscore","NO")
  ,("Debug on","False")
  ,("LibDir","/export/home/karel/src/ghc-7.6.1/inplace/lib")
  ,("Global Package
DB","/export/home/karel/src/ghc-7.6.1/inplace/lib/package.conf.d")
  ,("Gcc Linker
flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]")
  ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]")
  ]
karel@panda:/export/home/karel/src/ghc-7.6.1$
karel@panda:/export/home/karel/src/ghc-7.6.1$ ./inplace/bin/ghc-stage2
--make HelloWorld.hs
[1 of 1] Compiling Main             ( HelloWorld.hs, HelloWorld.o )
Linking HelloWorld ...
karel@panda:/export/home/karel/src/ghc-7.6.1$ ./HelloWorld
Hello World!
karel@panda:/export/home/karel/src/ghc-7.6.1$


Please keep in mind that GHC HEAD is completely different beast as there
is new codegen put on by defaul there and LLVM codegen is not working
correctly with it yet. Anyway, Austin Seipp seems to be working on
fixing that.

Thanks,
Karel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Karel Gardas
On 01/19/13 11:37 PM, Karel Gardas wrote:
>
> Hi,
>
> I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float
> ABI distro. I used distro provided LLVM 3.0 and configured GHC with:
>
> ./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0
>

Also the testsuite results run by:

make THREADS=2 WAY="normal threaded1 threaded2"

are here:

OVERALL SUMMARY for test run started at Sun Jan 20 10:33:22 CET 2013
     3400 total tests, which gave rise to
     8325 test cases, of which
        3 caused framework failures
     3835 were skipped

     4209 expected passes
      151 had missing libraries
       40 expected failures
        4 unexpected passes
       83 unexpected failures

Unexpected passes:
    profiling/should_compile  2410 (normal)
    profiling/should_compile  prof001 (normal)
    profiling/should_compile  prof002 (normal)
    th                        TH_spliceE5_prof (normal)

Unexpected failures:
    ../../libraries/base/tests/IO           4855 [exit code non-0]
(threaded1)
    ../../libraries/base/tests/IO           openFile008 [bad exit code]
(normal,threaded1,threaded2)
    ../../libraries/hpc/tests/function      subdir/tough2 [bad stderr]
(normal)
    ../../libraries/hpc/tests/function      tough [bad stderr]
(threaded1,threaded2)
    ../../libraries/hpc/tests/ghc_ghci      hpc_ghc_ghci [bad exit code]
(normal)
    ../../libraries/template-haskell/tests  dataToExpQUnit [exit code
non-0] (normal)
    annotations/should_compile              ann01 [exit code non-0] (normal)
    annotations/should_run                  annrun01 [exit code non-0]
(normal,threaded1,threaded2)
    codeGen/should_compile                  jmp_tbl [exit code non-0]
(normal)
    codeGen/should_compile                  massive_array [exit code
non-0] (normal)
    driver                                  T706 [bad exit code] (normal)
    ghc-api/T4891                           T4891 [bad exit code] (normal)
    ghc-api/apirecomp001                    apirecomp001 [bad exit code]
(normal)
    ghc-e/should_run                        2228 [bad exit code] (normal)
    ghc-e/should_run                        3890 [bad stderr] (normal)
    ghc-e/should_run                        ghc-e001 [bad exit code]
(normal)
    ghc-e/should_run                        ghc-e002 [bad exit code]
(normal)
    ghc-e/should_run                        ghc-e003 [bad exit code]
(normal)
    ghc-e/should_run                        ghc-e004 [bad stderr] (normal)
    ghc-e/should_run                        ghc-e005 [bad stderr] (normal)
    ghci/linking                            ghcilink001 [bad exit code]
(normal)
    ghci/linking                            ghcilink002 [bad exit code]
(normal)
    ghci/linking                            ghcilink003 [bad exit code]
(normal)
    ghci/linking                            ghcilink004 [bad exit code]
(normal)
    ghci/linking                            ghcilink005 [bad exit code]
(normal)
    ghci/linking                            ghcilink006 [bad exit code]
(normal)
    ghci/prog004                            ghciprog004 [bad exit code]
(normal)
    ghci/scripts                            ghci024 [bad exit code] (normal)
    ghci/scripts                            ghci037 [bad exit code] (normal)
    ghci/should_run                         3171 [bad stdout] (normal)
    perf/compiler                           T1969 [stat not good enough]
(normal)
    perf/compiler                           T3064 [stat not good enough]
(normal)
    perf/compiler                           T4801 [stat not good enough]
(normal)
    perf/compiler                           T5321FD [stat not good
enough] (normal)
    perf/compiler                           T5321Fun [stat not good
enough] (normal)
    perf/compiler                           T5631 [stat not good enough]
(normal)
    perf/compiler                           T5642 [stat not good enough]
(normal)
    perf/compiler                           T5837 [stat not good enough]
(normal)
    perf/compiler                           T783 [stat not good enough]
(normal)
    perf/compiler                           parsing001 [stat not good
enough] (normal)
    plugins                                 plugins01 [bad exit code]
(normal)
    plugins                                 plugins05 [exit code non-0]
(normal,threaded1,threaded2)
    plugins                                 plugins06 [exit code non-0]
(normal,threaded1)
    programs/barton-mangler-bug             barton-mangler-bug [exit
code non-0] (threaded2)
    programs/joao-circular                  joao-circular [exit code
non-0] (normal,threaded1,threaded2)
    quasiquotation/T4491                    T4491 [exit code non-0]
(normal,threaded1,threaded2)
    quasiquotation/qq007                    qq007 [exit code non-0] (normal)
    rts                                     3424 [exit code non-0]
(normal,threaded1)
    rts                                     T2615 [bad exit code]
(normal,threaded1,threaded2)
    rts                                     derefnull [bad exit code]
(threaded2)
    safeHaskell/flags                       Flags02 [exit code non-0]
(normal)
    th                                      T2700 [exit code non-0] (normal)
    th                                      T4135 [exit code non-0] (normal)
    th                                      T4188 [exit code non-0] (normal)
    th                                      T5037 [exit code non-0] (normal)
    th                                      T5362 [exit code non-0] (normal)
    th                                      TH_Depends [bad exit code]
(normal)
    th                                      TH_PromotedList [exit code
non-0] (normal)
    th                                      TH_RichKinds2 [exit code
non-0] (normal)
    th                                      TH_reifyDecl1 [exit code
non-0] (normal)
    th                                      TH_reifyDecl2 [exit code
non-0] (normal)
    th                                      TH_reifyInstances [exit code
non-0] (normal)
    th                                      TH_reifyMkName [exit code
non-0] (normal)
    th                                      TH_repGuard [exit code
non-0] (normal)
    th                                      TH_repPrim [exit code non-0]
(normal)
    th                                      TH_repPrim2 [exit code
non-0] (normal)
    th                                      TH_repUnboxedTuples [exit
code non-0] (normal)
    th                                      TH_unresolvedInfix [exit
code non-0] (normal)


So definitely something is working on ARM/Linux.

Karel

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
In reply to this post by Karel Gardas
Somebody claiming to be Karel Gardas wrote:
>I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI
>distro. I used distro provided LLVM 3.0 and configured GHC with:
>
>Please keep in mind that GHC HEAD is completely different beast as
>there is new codegen put on by defaul there and LLVM codegen is not working
>correctly with it yet.

Oh?  If LLVM codegen is broken in HEAD, that would explain why it's not
working for ARM :)  Hopefully I can get it working soon with at least an
unregistered build.  I have to build HEAD, since I'm doing cross-compiling.

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Karel Gardas
On 01/20/13 07:39 PM, Stephen Paul Weber wrote:

> Somebody claiming to be Karel Gardas wrote:
>> I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is
>> hard-float ABI distro. I used distro provided LLVM 3.0 and configured
>> GHC with:
>>
>> Please keep in mind that GHC HEAD is completely different beast as
>> there is new codegen put on by defaul there and LLVM codegen is not
>> working correctly with it yet.
>
> Oh? If LLVM codegen is broken in HEAD, that would explain why it's not
> working for ARM :) Hopefully I can get it working soon with at least an
> unregistered build. I have to build HEAD, since I'm doing cross-compiling.

The receipt is simple, first try LLVM-based build on fast x86 machine
(i.e. cd mk; cp build.mk.sample build.mk; edit to uncomment BuildFlavour
= quick-llvm) and once it's working attempt LLVM-based (the only way)
build on ARM.

Also, forget unregisterised build, rather ask Austin how is it looking
with his work on fixing LLVM codegen in HEAD.

And a last note: please keep in mind that cross-compiling is supported
only using NCG. LLVM is completely out of question now, so you will have
some work here anyway. I don't think it'll be complicated, but certainly
some hacking with passing target triplet down to LLVM, but IIRC you've
already found that anyway...

Karel


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Simon Marlow-7
In reply to this post by Stephen Paul Weber
On 19/01/13 07:32, Stephen Paul Weber wrote:

> Somebody claiming to be Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> Was that an registerised or unregisterised build?
>>> Did anyone succesfully build ghc on an arm system which produces non
>>> crashing executables?
>>
>> Just finally got a BB10 device set up so I can test my cross-compiler
>> on the ARM
>>
>> I'm about to try a configuration with --enable-unregisterised to see
>> if that helps.
>
> make -r --no-print-directory -f ghc.mk phase=final all
> "inplace/bin/ghc-stage1" -static  -H64m -O0 -fasm    -package-name
> integer-simple-0.1.1.0 -hide-all-packages -i
> -ilibraries/integer-simple/.
> -ilibraries/integer-simple/dist-install/build
> -ilibraries/integer-simple/dist-install/build/autogen
> -Ilibraries/integer-simple/dist-install/build
> -Ilibraries/integer-simple/dist-install/build/autogen
> -Ilibraries/integer-simple/.    -optP-include
> -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h
> -package ghc-prim-0.3.1.0  -package-name integer-simple -Wall
> -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples
> -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O
> -fasm  -no-user-package-db -rtsopts      -odir
> libraries/integer-simple/dist-install/build -hidir
> libraries/integer-simple/dist-install/build -stubdir
> libraries/integer-simple/dist-install/build -hisuf hi -osuf  o -hcsuf hc
> -c libraries/integer-simple/./GHC/Integer/Type.hs -o
> libraries/integer-simple/dist-install/build/GHC/Integer/Type.o
>
> when making flags consistent: Warning:
>      Compiler unregisterised, so compiling via C
> /tmp/ghc25891_0/ghc25891_0.hc: In function 'c2pA_entry':
>
> /tmp/ghc25891_0/ghc25891_0.hc:3691:1:
>       warning: this decimal constant is unsigned only in ISO C90
> [enabled by default]
>
> /tmp/ghc25891_0/ghc25891_0.hc:3691:17:
>       error: expected ')' before numeric constant
> make[1]: ***
> [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1
> make: *** [all] Error 2

Strange, I didn't see this on my builds, which I think is the same as
yours (GHC HEAD, cross-compiling for RPi with --enable-unregisterised).

If you make a ticket with full details, I can try to reproduce.

Cheers,
        Simon



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Nathan Hüsken
In reply to this post by Nathan Hüsken
Hey,

For me thinks have changed.
With the current ghc HEAD and llvm version 3.2 I am able to do a
registerised build for android!
I have not tested much, but Hello World works.
Regards,
Nathan

On 01/14/2013 06:15 PM, Nathan Hüsken wrote:

> In a different thread (Error building ghc on raspberry pi):
>
> On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
>>
>> I did eventually finish building stage2, but the final executable
> segfaulted on start.
>> I haven't investigated much why that happened, the days it takes to
> rebuild it just
>> made me give up.
>
> Was that an registerised or unregisterised build?
> Did anyone succesfully build ghc on an arm system which produces non
> crashing executables?
>
> I am asking, because I build a arm-linux-androideabi cross compiler, but
> the executables crash.
> Only in an unregisterised build, they work.
>
> So I wonder if it is a general arm problem or has to do with android.
>
> Thanks!
> Nathan
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
Somebody claiming to be Nathan Hüsken wrote:
>Hey,
>
>For me thinks have changed.
>With the current ghc HEAD and llvm version 3.2 I am able to do a
>registerised build for android!

Do you think it is specifically the 3.2 that made it work?

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Nathan Hüsken
On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> Hey,
>>
>> For me thinks have changed.
>> With the current ghc HEAD and llvm version 3.2 I am able to do a
>> registerised build for android!
>
> Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work. Stephen Blackheath found that out, see here:
http://www.haskell.org/pipermail/iphone/2013-January/000212.html


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber
Somebody claiming to be Nathan Hüsken wrote:
>On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> With the current ghc HEAD and llvm version 3.2 I am able to do a
>>> registerised build for android!
>> Do you think it is specifically the 3.2 that made it work?
>
>Yes. With llvm version 3.1 I was only able to get an unregisterised
>build to work.

Did you have to hack the source ala
<http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
?

>Stephen Blackheath found that out, see here:
>http://www.haskell.org/pipermail/iphone/2013-January/000212.html

 From that post, it seems like llvm-3.0 might also work?

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
123