Thanks for the heads-up, ARM is not that essential, and PowerPC would
be sufficient for my purposes a.t.m.
Cheers,
Gabor
On 7/11/12, Karel Gardas <[email protected]> wrote:
>
> Hi Gabor,
>
> thanks a lot for your effort on GHC cross-compilation. You are talking
> about cross-compiling to ARM too. I would like to warn you here as GHC
> HEAD build for ARM is broken since February due to LLVM backend
> miscompiling stage2 -- at least that's my analysis of this so far. See
> http://hackage.haskell.org/trac/ghc/ticket/7049
>
> Hopefully once GHC/LLVM unbreaks I will be more than happy to test your
> stuff for {solaris|linux}/x86->linux/arm cross-compilation.
>
> Thanks!
> Karel
>
> On 07/11/12 12:19 PM, Gabor Greif wrote:
>> Hi all,
>>
>> coming back on the cross compilers issue. As you know, I had a working
>> PPC cross compiler in a github fork that did not require any alien
>> tools, just a cross-gcc to distill all characteristics of the platform
>> that are needed by GHC.
>>
>> Unfortunately this fork has bitrotten somewhat (mostly because the
>> alien-cross merge). Now I have some energy to port my solution to
>> HEAD. The question is how you feel about my suggested approach:
>>
>> 1) get all non-conflicting changes on HEAD (i.e. put them into the
>> official repo). These are:
>> * the 'awk' scripts (*) and makefile changes to create the target
>> constants (sizes, offsets).
>>
>> 2) make sure there are no regressions for some nights, so we can be
>> confident that I did not break anything.
>>
>> 3) The currently conflicting (though not invasively) modifications.
>> These include:
>> * the 2-stage build changes (**) still needed in makefiles and
>> configury (if still necessary). These include "--with-cross-gcc"
>> detection etc.
>> * the modifications to the GHC wrapper script. I have something
>> small working, but an experienced GHC implementor surely can point me
>> to a more general approach.
>> * modifications to the building of the libraries, so that the
>> correct cross-compiling options are passed to the package builds.
>>
>> 4) again, observe the bot for some time whether stuff borked, get some
>> beta testers into the boat, implement feedback.
>>
>> 5) Add some tests that exercise cross compilation (e.g. x86_64 host,
>> i386 target or x64 target with 32-bit pointer API on Linux). For
>> setting up these I'd ask for some help from the more experienced of
>> you.
>>
>>
>> It remains to clarify whether I can obtain commit privileges for the
>> above steps w.r.t. the HEAD branch of the official repo. I believe
>> that these privileges would speed up the porting a lot. For 1) I would
>> ask for post-commit review and for 3) I'd suggest pre-integration on a
>> branch followed by a pre-merge review, then merge to HEAD.
>> Alternatively, I'd just try to pull this off in a new github fork and
>> ask you for pulls to the official (if you feel hesitant about granting
>> me the privileges).
>>
>> A bit of background... I got official permission to evaluate Haskell
>> in an embedded programming context for research projects from my
>> employer (Alcatel-Lucent). I have to present concrete evidence that
>> this direction of attack results in usable artifacts for our research
>> this summer, as the proposal for continuation of said activity will be
>> concluded in September.
>>
>> Thanks for your attention and in hope for cooperation,
>>
>> cheers,
>>
>> Gabor
>>
>> (*) I promise to convert all 'awk' scripts to 'runhaskell' scripts as
>> soon as the cross-compilation works from vanilla HEAD for PowerPC and
>> ARM.
>> (**) ultimately we'll need a 3-stage build for cross compilation,
>> because I consider Template Haskell as essential.
>>
>> _______________________________________________
>> Cvs-ghc mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>>
>
>
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
