Nathan Hüsken | 14 Jan 18:15 2013
Picon

any successfull ghc registerised builds on arm?

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
Stefan Kersten | 14 Jan 18:57 2013
Picon

Re: any successfull ghc registerised builds on arm?

hi nathan,

On Jan 14, 2013, at 6:15 PM, Nathan Hüsken <nathan.huesken <at> posteo.de> 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
Karel Gardas | 14 Jan 19:02 2013
Picon

Re: any successfull ghc registerised builds on arm?

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
Stephen Paul Weber | 19 Jan 07:04 2013
Picon

Re: any successfull ghc registerised builds on arm?

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 <at> 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,  <at> singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Stephen Paul Weber | 19 Jan 07:32 2013
Picon

Re: any successfull ghc registerised builds on arm?

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
(Continue reading)

Stephen Paul Weber | 19 Jan 07:45 2013
Picon

Re: any successfull ghc registerised builds on arm?

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?

(Continue reading)

Nathan Hüsken | 19 Jan 11:28 2013
Picon

Re: any successfull ghc registerised builds on arm?

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 )
(Continue reading)

Ben Gamari | 19 Jan 17:46 2013
Picon

Re: any successfull ghc registerised builds on arm?

Stephen Paul Weber <singpolyma <at> singpolyma.net> 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
Stephen Paul Weber | 19 Jan 19:01 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Ben Gamari wrote:
>Stephen Paul Weber <singpolyma <at> singpolyma.net> 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,  <at> singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
Karel Gardas | 19 Jan 23:37 2013
Picon

Re: any successfull ghc registerised builds on arm?


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")
(Continue reading)

Karel Gardas | 20 Jan 18:13 2013
Picon

Re: any successfull ghc registerised builds on arm?

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)
(Continue reading)

Stephen Paul Weber | 20 Jan 19:39 2013
Picon

Re: any successfull ghc registerised builds on arm?

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,  <at> singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
Karel Gardas | 20 Jan 19:50 2013
Picon

Re: any successfull ghc registerised builds on arm?

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
(Continue reading)

Simon Marlow | 21 Jan 14:33 2013
Picon

Re: any successfull ghc registerised builds on arm?

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
(Continue reading)

Nathan Hüsken | 24 Jan 15:52 2013
Picon

Re: any successfull ghc registerised builds on arm?

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.
> 
(Continue reading)

Stephen Paul Weber | 24 Jan 15:58 2013
Picon

Re: any successfull ghc registerised builds on arm?

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,  <at> singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Nathan Hüsken | 24 Jan 16:21 2013
Picon

Re: any successfull ghc registerised builds on arm?

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
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Stephen Paul Weber | 24 Jan 16:28 2013
Picon

Re: any successfull ghc registerised builds on arm?

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,  <at> singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
(Continue reading)

Nathan Hüsken | 24 Jan 16:41 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
> 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>
> ?

Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

> 
>> 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?
> 

At the time of that post, ghc did not compile with 3.0 or 3.2.
I have sticked to 3.2, and ghc compiles with it now. I do not know about
3.0.

(Continue reading)

Stephen Paul Weber | 24 Jan 16:50 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Nathan Hüsken wrote:
>On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>>>> 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.
>> <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
>> ?
>
>Not exactly, see the patch here:
>http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not 
doing me any favours...

How the heck am I supposed to figure out what that string should be? :(

That said... how did you get an unregisterised build to work with an LLVM 
backend?  Everything I've seen in the code implied that the moment you are 
unregisteried, it uses via-C...  Which is what my above patch is primarily 
about.

--

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
(Continue reading)

Karel Gardas | 24 Jan 17:04 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/13 04:50 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>>>>> 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.
>>> <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
>>>
>>> ?
>>
>> Not exactly, see the patch here:
>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>> and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
>
> Oh, man, the fact that I don't have that setting for QNX is probably not
> doing me any favours...

IIRC it's more about optimization, i.e. proper data type alignment.

> How the heck am I supposed to figure out what that string should be? :(

Described here: http://llvm.org/docs/LangRef.html#data-layout -- for 
LLVM 3.3. General rule, I would start with what Linux requires and check 
from that.

> That said... how did you get an unregisterised build to work with an
> LLVM backend? Everything I've seen in the code implied that the moment
> you are unregisteried, it uses via-C... Which is what my above patch is
> primarily about.

(Continue reading)

Nathan Hüsken | 24 Jan 17:59 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 05:04 PM, Karel Gardas wrote:
> On 01/24/13 04:50 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>>>>>> 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.
>>>> <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
>>>>
>>>>
>>>> ?
>>>
>>> Not exactly, see the patch here:
>>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>>> and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
>>
>> Oh, man, the fact that I don't have that setting for QNX is probably not
>> doing me any favours...
> 
> IIRC it's more about optimization, i.e. proper data type alignment.
> 
>> How the heck am I supposed to figure out what that string should be? :(
> 
> Described here: http://llvm.org/docs/LangRef.html#data-layout -- for
> LLVM 3.3. General rule, I would start with what Linux requires and check
> from that.
> 
>> That said... how did you get an unregisterised build to work with an
>> LLVM backend? Everything I've seen in the code implied that the moment
>> you are unregisteried, it uses via-C... Which is what my above patch is
(Continue reading)

Stephen Paul Weber | 24 Jan 17:51 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Stephen Paul Weber wrote:
>Somebody claiming to be Nathan Hüsken wrote:
>>On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>>>>>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.
>>><http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
>>>?
>>
>>Not exactly, see the patch here:
>>http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>>and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
>
>Oh, man, the fact that I don't have that setting for QNX is probably 
>not doing me any favours...

I tried the following:

diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
index 218870a..a583ffc 100644
--- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
 <at>  <at>  -58,6 +58,9  <at>  <at>  moduleLayout = sdocWithPlatform $ \platform ->
      Platform { platformArch = ArchARM {}, platformOS = OSLinux } ->
          text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
          $+$ text "target triple = \"arm-unknown-linux-gnueabi\""
+    Platform { platformArch = ArchARM {}, platformOS = OSQNXNTO } ->
+        text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\""
+        $+$ text "target triple = \"arm-unknown-nto-qnx8.0.0eabi\""
      _ ->
(Continue reading)

Nathan Hüsken | 24 Jan 18:06 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 05:51 PM, Stephen Paul Weber wrote:
(...)
> 
> So... it can't find memcpy for some reason?
> 
> I'm about to try with llvm-3.2 to see if that's different.
> 

I had similar problems with mkfifo. I believe the reason was, that in
the android nkd mkfifo is inlined.

The solution for me was to wrap mkfifo (in a function I called __mkfifo)
and used that one from the ffi instead.

But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?
Stephen Paul Weber | 24 Jan 18:28 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Nathan Hüsken wrote:
>On 01/24/2013 05:51 PM, Stephen Paul Weber wrote:
>(...)
>>
>> So... it can't find memcpy for some reason?
>>
>> I'm about to try with llvm-3.2 to see if that's different.
>>
>
>The solution for me was to wrap mkfifo (in a function I called __mkfifo)
>and used that one from the ffi instead.

Right, I see things around on the web about people doing similar stuff.

>But the symbol not found is __aeabi_memcpy, not memcpy itself ...
>I can not find __aeabi_memcpy in the ghc source ...
>Maybe it is not linking some required library?

I'm not sure.  Most curious is that this has not come up before in any of my 
other ARM-build attempts (which produced less-than-working code, but 
suceeded in compiling).

--

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
(Continue reading)

Stephen Paul Weber | 24 Jan 18:51 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Stephen Paul Weber wrote:
>Somebody claiming to be Nathan Hüsken wrote:
>>But the symbol not found is __aeabi_memcpy, not memcpy itself ...
>>I can not find __aeabi_memcpy in the ghc source ...
>>Maybe it is not linking some required library?
>
>I'm not sure.  Most curious is that this has not come up before in 
>any of my other ARM-build attempts (which produced less-than-working 
>code, but suceeded in compiling).

This seems to be a general ARM thing: 
<http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html> 
... so not sure why I'm getting it and no one else is.

--

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Karel Gardas | 24 Jan 19:01 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/13 06:51 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> But the symbol not found is __aeabi_memcpy, not memcpy itself ...
>>> I can not find __aeabi_memcpy in the ghc source ...
>>> Maybe it is not linking some required library?
>>
>> I'm not sure. Most curious is that this has not come up before in any
>> of my other ARM-build attempts (which produced less-than-working code,
>> but suceeded in compiling).
>
> This seems to be a general ARM thing:
> <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html>
> ... so not sure why I'm getting it and no one else is.

Copy your last ghc-stage1 invocation step, add "-v -keep-tmp-files" and 
see what it'll execute for you. At least you should see libraries which 
are going into the link process.

Then write C hello world, compile and link it and see what's going 
inside linking and compare with ghc. I guess some lib will be missing in 
case of ghc linking phase so you'll need to add it either into 
mk/build.mk appropriate option (E.g. -optl-l<your lib>) or just hack 
DynFlags.hs to include this for you.

Karel

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
(Continue reading)

Karel Gardas | 24 Jan 18:48 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
> Doing a registered build with llvm-3.0 I eventually get:
>
> "inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs
> -static -H64m -O0 -fllvm -hide-all-packages -i -iutils/hsc2hs/.
> -iutils/hsc2hs/dist-install/build
> -iutils/hsc2hs/dist-install/build/autogen
> -Iutils/hsc2hs/dist-install/build
> -Iutils/hsc2hs/dist-install/build/autogen -optP-include
> -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package
> base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1
> -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP
> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir
> utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build
> -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc
> utils/hsc2hs/dist-install/build/Main.o
> utils/hsc2hs/dist-install/build/HSCParser.o
> utils/hsc2hs/dist-install/build/DirectCodegen.o
> utils/hsc2hs/dist-install/build/CrossCodegen.o
> utils/hsc2hs/dist-install/build/UtilsCodegen.o
> utils/hsc2hs/dist-install/build/Common.o
> utils/hsc2hs/dist-install/build/C.o
> utils/hsc2hs/dist-install/build/Flags.o
> utils/hsc2hs/dist-install/build/Paths_hsc2hs.o
> /home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
> In function `c4Uj_info':
> ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy'
> /home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
> In function `c4XO_info':
> ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy'
(Continue reading)

Stephen Paul Weber | 24 Jan 19:00 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Karel Gardas wrote:
>On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>>Doing a registered build with llvm-3.0 I eventually get:
>>In function `c58Y_info':
>>/tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to
>>`__aeabi_memcpy'
>>collect2: ld returned 1 exit status
>>make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1
>>make: *** [all] Error 2
>>
>This is purely linker issue.  Somehow you link with different set of 
>libraries probably.  Anyway it looks like: 
>http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html 
>-- this function is part of common ARM EABI so it should be implemented by 
>your C compiler tool-chain. You just need to find out where it is and how 
>you may use it.

So, not sure on the right solution, but when I add   -lcaps    then the 
linker errors go away and I can build executables.  Unfortunately, when I 
try to run any of them on a device, I get a segfault, just as I always did 
with registerised cross-builds for ARM... this with both llvm-3.0 and 
llvm-3.2

:(

--

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

Nathan Hüsken | 24 Jan 19:02 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Karel Gardas wrote:
>> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>>> Doing a registered build with llvm-3.0 I eventually get:
>>> In function `c58Y_info':
>>> /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to
>>> `__aeabi_memcpy'
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1
>>> make: *** [all] Error 2
>>>
>> This is purely linker issue.  Somehow you link with different set of
>> libraries probably.  Anyway it looks like:
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html
>> -- this function is part of common ARM EABI so it should be
>> implemented by your C compiler tool-chain. You just need to find out
>> where it is and how you may use it.
> 
> So, not sure on the right solution, but when I add   -lcaps    then the
> linker errors go away and I can build executables.  Unfortunately, when
> I try to run any of them on a device, I get a segfault, just as I always
> did with registerised cross-builds for ARM... this with both llvm-3.0
> and llvm-3.2
> 
> :(
> 
Can you run it in gdb and loock what the backtrace looks like?
Stephen Paul Weber | 24 Jan 19:09 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Nathan Hüsken wrote:
>On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Karel Gardas wrote:
>>> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>> :(
>>
>Can you run it in gdb and loock what the backtrace looks like?

I can maybe get a core file and load it into gdb.  I may try that soon.

--

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Stephen Paul Weber | 24 Jan 19:26 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Nathan Hüsken wrote:
>On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Karel Gardas wrote:
>>> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>> So, not sure on the right solution, but when I add   -lcaps    then the
>> linker errors go away and I can build executables.  Unfortunately, when
>> I try to run any of them on a device, I get a segfault, just as I always
>> did with registerised cross-builds for ARM... this with both llvm-3.0
>> and llvm-3.2
>>
>> :(
>>
>Can you run it in gdb and loock what the backtrace looks like?

[New pid 14037182 tid 1]
Program terminated with signal 11, Segmentation fault.
#0  0x08502000 in ?? ()
(gdb) bt
#0  0x08502000 in ?? ()
#1  0x082ce4c4 in ?? ()
#2  0x082ce4c4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

--

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

_______________________________________________
(Continue reading)

Nathan Hüsken | 24 Jan 19:28 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
>>> Somebody claiming to be Karel Gardas wrote:
>>>> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>>> So, not sure on the right solution, but when I add   -lcaps    then the
>>> linker errors go away and I can build executables.  Unfortunately, when
>>> I try to run any of them on a device, I get a segfault, just as I always
>>> did with registerised cross-builds for ARM... this with both llvm-3.0
>>> and llvm-3.2
>>>
>>> :(
>>>
>> Can you run it in gdb and loock what the backtrace looks like?
> 
> [New pid 14037182 tid 1]
> Program terminated with signal 11, Segmentation fault.
> #0  0x08502000 in ?? ()
> (gdb) bt
> #0  0x08502000 in ?? ()
> #1  0x082ce4c4 in ?? ()
> #2  0x082ce4c4 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

Not very informative :).
Did you compile with -debug?
I remember I got a stack trace with gdb like this (when doing remote
debugging) and got it cleaned up by loading the exectuable with "file".
Maybe you have to do something like that to?
(Continue reading)

David Terei | 24 Jan 20:44 2013
Picon

Re: any successfull ghc registerised builds on arm?

Hi all,

Can people please file bugs about these issues when they are confirmed
to some degree? Lots of ARM & LLVM stuff seems to just be floating
around mailing lists.... much higher chance of me or someone else
fixing if there are filed bug reports with test cases and/or patches
attached.

Austin and I also fixed a couple of LLVM related issues in the last 2
days or so, so hopefully that solved some of these.

Top level bugs to link to when filing other bugs please:

* GHC ARM support: http://hackage.haskell.org/trac/ghc/ticket/7623
* LLVM Cross compilation: http://hackage.haskell.org/trac/ghc/ticket/7610
* LLVM unregisterised issues: http://hackage.haskell.org/trac/ghc/ticket/7622
* LLVM bootstrap issues: http://hackage.haskell.org/trac/ghc/ticket/7590

Cheers,
David

On 24 January 2013 10:28, Nathan Hüsken <nathan.huesken <at> posteo.de> wrote:
> On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:
>>>> Somebody claiming to be Karel Gardas wrote:
>>>>> On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
>>>> So, not sure on the right solution, but when I add   -lcaps    then the
>>>> linker errors go away and I can build executables.  Unfortunately, when
>>>> I try to run any of them on a device, I get a segfault, just as I always
(Continue reading)

Stephen Paul Weber | 24 Jan 23:59 2013
Picon

Re: any successfull ghc registerised builds on arm?

Somebody claiming to be Nathan Hüsken wrote:
>On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> Can you run it in gdb and loock what the backtrace looks like?
>Did you compile with -debug?
>I remember I got a stack trace with gdb like this (when doing remote
>debugging) and got it cleaned up by loading the exectuable with "file".
>Maybe you have to do something like that to?

$ ntoarm-gdb --core=Main.core Main
... copyright and such ...

[New pid 14336138 tid 1]

warning: .dynamic section for
"/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1" is not at the
expected address (wrong library or version mismatch?)

warning: .dynamic section for
"/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1" is not at
the expected address (wrong library or version mismatch?)
Program terminated with signal 11, Segmentation fault.
#0  0x08402000 in ?? ()
(gdb) bt
#0  0x08402000 in ?? ()
#1  0x082de978 in stg_ap_p_fast ()
#2  0x082de978 in stg_ap_p_fast ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

--

-- 
(Continue reading)

Nathan Hüsken | 25 Jan 10:01 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 11:59 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
>>> Somebody claiming to be Nathan Hüsken wrote:
>>>> Can you run it in gdb and loock what the backtrace looks like?
>> Did you compile with -debug?
>> I remember I got a stack trace with gdb like this (when doing remote
>> debugging) and got it cleaned up by loading the exectuable with "file".
>> Maybe you have to do something like that to?
> 
> $ ntoarm-gdb --core=Main.core Main
> ... copyright and such ...
> 
> [New pid 14336138 tid 1]
> 
> warning: .dynamic section for
> "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1"
> is not at the expected address (wrong library or version mismatch?)
> 
> warning: .dynamic section for
> "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1"
> is not at the expected address (wrong library or version mismatch?)
> Program terminated with signal 11, Segmentation fault.
> #0  0x08402000 in ?? ()
> (gdb) bt
> #0  0x08402000 in ?? ()
> #1  0x082de978 in stg_ap_p_fast ()
> #2  0x082de978 in stg_ap_p_fast ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
(Continue reading)

Karel Gardas | 26 Jan 20:04 2013
Picon

Re: any successfull ghc registerised builds on arm?


Now, the question is: does QNX use the same ABI as Linux on ARM? See ARM 
EABI notes in includes/stg/MachRegs.h

Karel

On 01/24/13 11:59 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
>>> Somebody claiming to be Nathan Hüsken wrote:
>>>> Can you run it in gdb and loock what the backtrace looks like?
>> Did you compile with -debug?
>> I remember I got a stack trace with gdb like this (when doing remote
>> debugging) and got it cleaned up by loading the exectuable with "file".
>> Maybe you have to do something like that to?
>
> $ ntoarm-gdb --core=Main.core Main
> ... copyright and such ...
>
> [New pid 14336138 tid 1]
>
> warning: .dynamic section for
> "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1"
> is not at the expected address (wrong library or version mismatch?)
>
> warning: .dynamic section for
> "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1"
> is not at the expected address (wrong library or version mismatch?)
> Program terminated with signal 11, Segmentation fault.
> #0 0x08402000 in ?? ()
(Continue reading)

Nathan Hüsken | 24 Jan 17:58 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 01/24/2013 04:50 PM, Stephen Paul Weber wrote:
> Somebody claiming to be Nathan Hüsken wrote:
>> On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>>>>> 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.
>>> <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
>>>
>>> ?
>>
>> Not exactly, see the patch here:
>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>> and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
> 
> Oh, man, the fact that I don't have that setting for QNX is probably not
> doing me any favours...
> 
> How the heck am I supposed to figure out what that string should be? :(

Do you mean the data layout? Actually, I have to admit I just copied it
from arm linux.

> 
> That said... how did you get an unregisterised build to work with an
> LLVM backend?  Everything I've seen in the code implied that the moment
> you are unregisteried, it uses via-C...  Which is what my above patch is
> primarily about.
> 

I ... it just worked :). I passed --enable-unregistered to configure and
(Continue reading)

Simon Marlow | 25 Jan 11:29 2013
Picon

Re: any successfull ghc registerised builds on arm?

On 24/01/13 16:58, Nathan Hüsken wrote:
> On 01/24/2013 04:50 PM, Stephen Paul Weber wrote:
>> Somebody claiming to be Nathan Hüsken wrote:
>>> On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
>>>>>> 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.
>>>> <http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch>
>>>>
>>>> ?
>>>
>>> Not exactly, see the patch here:
>>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
>>> and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs
>>
>> Oh, man, the fact that I don't have that setting for QNX is probably not
>> doing me any favours...
>>
>> How the heck am I supposed to figure out what that string should be? :(
>
> Do you mean the data layout? Actually, I have to admit I just copied it
> from arm linux.
>
>>
>> That said... how did you get an unregisterised build to work with an
>> LLVM backend?  Everything I've seen in the code implied that the moment
>> you are unregisteried, it uses via-C...  Which is what my above patch is
>> primarily about.
>>
>
(Continue reading)


Gmane