The Glasgow Haskell Compiler port is marked as i386/amd64 only even though it appears that upstream support multiple architectures. A small porting project is probably required to scope out what needs to be modified in the port to support ARMv6. When adding ARMv6 to the list of supported architectures, the build bails: ===> Returning to build of ghc-7.8.3_1 =========================================================================== ====>> Recording filesystem state for prebuild... done =======================<phase: configure >============================ ===> ghc-7.8.3_1 depends on file: /usr/local/share/xsl/docbook/html - found ===> ghc-7.8.3_1 depends on file: /usr/local/bin/xsltproc - found ===> ghc-7.8.3_1 depends on executable: gmake - found ===> ghc-7.8.3_1 depends on executable: gcc48 - found ===> ghc-7.8.3_1 depends on file: /usr/local/bin/as - found ===> ghc-7.8.3_1 depends on file: /usr/local/bin/autoconf-2.69 - found ===> ghc-7.8.3_1 depends on file: /usr/local/bin/perl5.18.4 - found ===> ghc-7.8.3_1 depends on shared library: libgmp.so - found (/usr/local/lib/libgmp.so.10.1.3) ===> ghc-7.8.3_1 depends on shared library: libffi.so.6 - found (/usr/local/lib/libffi.so.6.0.4) ===> ghc-7.8.3_1 depends on shared library: libiconv.so.3 - found (/usr/local/lib/libiconv.so.2.5.1) ===> Configuring for ghc-7.8.3_1 cd: /wrkdirs/usr/ports/lang/ghc/work/ghc-7.6.3-boot: No such file or directory *** Error code 2 Stop. make: stopped in /usr/ports/lang/ghc
Auto-assigned to maintainer haskell@FreeBSD.org
That is because in order to build GHC you will need a GHC. Currently, we only have bootstrap compilers prepared for i386 and amd64, that is why they are mentioned as the only supported architectures. Officially there is no FreeBSD/arm support for GHC at upstream, but I admit that recently Linux and iOS have gained some of it [1,2]. Building a bootstrap compiler requires some handcrafted magic, explained at the GHC developer's wiki [3,4] -- I cannot tell how much additional effort would be required for this. Personally, I have not got to investigate this, but as far as I know, Olivier Houchard (cognet@) has some preliminary porting experiences with GHC. Please note that I have been running buildbots for the i386 and amd64 platforms for GHC-head [5], so if you manage to get something up and running on armv6, I could add a buildbot for that as well, so we could monitor its health. If you join #haskell-FreeBSD @ Freenode then I am happy to answer any further related questions. [1] https://ghc.haskell.org/trac/ghc/wiki/Platforms [2] https://ghcarm.wordpress.com/ [3] https://ghc.haskell.org/trac/ghc/wiki/Building [4] https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling [5] http://haskell.inf.elte.hu/builders/
Created attachment 159455 [details] armv6 fix Hi, I've successfully compiled an "unregisterised" version of ghc for armv6 (thanks Gábor for your help) Some issues I encounter: I'm hitting this problem at runtime: https://ghc.haskell.org/trac/ghc/ticket/9673 I've tried to use ld.gold but the issue is still there (I may have missed something) Compiling with -O0 just works (cf SRC_HC_OPTS, GhcStage*HcOpts in the patch) ghc-stage1 has a .text segment larger than the default maximum set by the kernel. Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [13] .text PROGBITS 00014168 004168 474c7fc 00 AX 0 0 8 error message: Text segment size exceeds system limit Abort This issue is solved with: sysctl kern.maxtsiz=80000000 The DYNAMIC option is mandatory on armv6: ghc.mk:159: *** dyn is not in $(GhcLibWays), but $(DYNAMIC_GHC_PROGRAMS) is YES. Stop. I can't find a way to make it mandatory for armv6 using the 'options' framework (or any other means) I've attached a patch for review. I've heard that you'll update ghc to a newer version, let me know if you want me to generate a patch against your development repository. The boostrap binaries can be found here: http://mikael.urankar.free.fr/FreeBSD/arm/ghc-7.8.3-arm-freebsd11-boot.tar.bz2 build log with BOOT option on: http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/ghc-7.8.3_1_boot_option_on.log build log with BOOT option off: http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/ghc-7.8.3_1_boot_option_off.log
Unfortunately, I do not have an armv6 development environment around to experiment with. (Although, perhaps I may be able to get something up and working through the QEMU support in poudriére). Regarding the bootstrap compiler, I have the following comments to consider before moving on: - As far as I am aware, FreeBSD 10.x officially comes with armv6 support, so probably there should be a separate version created for 10. Of course, for a time being this is not a serious issue, but it is also something to be worth keeping in mind. - According to the GHC porting guide, building the "unregisterised" version of the compiler is only the first step in making GHC work on a new platform. Its performance is quite suboptimal (due to the missing support for native code generation) and it may also explain the problems that you are also experiencing. For example, it cannot do object splitting that could be a reason for running of the memory during linking. - It might be better to experiment with a more recent version of the compiler, 7.10.2 has just been released -- that could be a better bootstrapping option to choose in the long run. It probably has a better support for ARM too. I am also recommending this because I have been indeed working on a major update that brings GHC 7.10 to the ports tree. It is mostly done and can be found in the development repository [1]. Regarding forcing the DYNAMIC option to be on for armv6 (although I am a bit doubtful if this is really the case), you could just change the respective conditionals in bsd.cabal.mk to add the necessary configuration flags unconditionally when building for ARM. [1] https://github.com/freebsd-haskell/ports
Created attachment 192347 [details] patch Hi, I've managed to build the "registerised" version of ghc-8.4.1 for armv6, armv7 and aarch64 with the attached patch and the following bootstrap compilers: http://mikael.urankar.free.fr/FreeBSD/aarch64/ghc-8.4.1-boot-aarch64-unknown-freebsd.tar.xz http://mikael.urankar.free.fr/FreeBSD/arm/ghc-8.4.1-boot-armv6-unknown-freebsd.tar.xz http://mikael.urankar.free.fr/FreeBSD/arm/ghc-8.4.1-boot-armv7-unknown-freebsd.tar.xz They're based on 12-CURRENT (I don't have time or resources to do the same work on -RELEASE or -STABLE.) Building ghc under emulation (with qemu-user-static) doesn't work. There is an issue with CABAL_ARCH, it's always set to x86_64 even for arm* arch and I don't know how to fix it: root@12armv7: uname -p armv7 root@12armv7: make -C textproc/hs-case-insensitive -V CABAL_ARCH x86_64 Templates/config.sub and Templates/config.guess should be in a separate bug report, I'll do that later. My patch wasn't tested at all on amd64.
Created attachment 192349 [details] patch
I'll take a look at that after https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227968 lands. It would also be helpful, if you rebase your current work on top of my patch from PR 227968.
Created attachment 193949 [details] patch regen after ports r470870 bootstrap available here: ttp://mikael.urankar.free.fr/FreeBSD/aarch64/ghc-8.4.2-boot-aarch64-freebsd.tar.xz http://mikael.urankar.free.fr/FreeBSD/arm/ghc-8.4.2-boot-armv6-freebsd.tar.xz http://mikael.urankar.free.fr/FreeBSD/arm/ghc-8.4.2-boot-armv7-freebsd.tar.xz
build logs: http://mikael.urankar.free.fr/FreeBSD/aarch64/build_logs/ghc-8.4.2-aarch64.log http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/ghc-8.4.2-armv6.log
(In reply to mikael.urankar from comment #8) Do you think we should host the bootstrap bits in the distcache somewhere?
(In reply to mikael.urankar from comment #8) What is the reason to use gold and llvm50?
(In reply to Sean Bruno from comment #10) I overlooked this part, it would be nice if the bootstrap are hosted somewhere on freebsd.org (what is distcache?)
(In reply to Gleb Popov from comment #11) llvm is mandatory on arm* to build the registerised version [1] ld.gold is the only linker that produces working binaries (all other linker I tried makes ghc-stage2 crash) clang also produces bad binaries (with ld.gold as a linker) To recap, the only working toolchain combination is: gcc + ld.gold. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/ARMLinuxGnuEABI
(In reply to mikael.urankar) > I overlooked this part, it would be nice if the bootstrap are hosted somewhere on freebsd.org (what is distcache?) I host my bootstraps on people.freebsd.org. I can also host yours when we get this committed. > llvm is mandatory on arm* to build the registerised version [1] ld.gold is the only linker that produces working binaries (all other linker I tried makes ghc-stage2 crash) Ok, but why LLVM 5.0? Doesn't 6.0 work? > clang also produces bad binaries (with ld.gold as a linker) Have you tried lld?
(In reply to Gleb Popov from comment #14) I have to use gcc for arm* and gcc doesn't recognize lld as a linker: gcc6: error: unrecognized command line option '-fuse-ld=lld'; did you mean '-fuse-ld=bfd'? I can try with lld if bug #227302 lands. llvm60 is not a 'suppported' version for ghc-8.4.2, I'll let you read [1] for details. [1] https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
It is hard to comment on the patch, would you mind creating a diff on Phabricator? http://reviews.freebsd.org/
(In reply to Gleb Popov from comment #16) done, it's the first time I use phab, I hope it's ok: https://reviews.freebsd.org/D15674
A commit references this bug: Author: arrowd Date: Fri Aug 31 08:51:35 UTC 2018 New revision: 478531 URL: https://svnweb.freebsd.org/changeset/ports/478531 Log: lang/ghc: Add support for ARM arches: aarch64, armv6, armv7. PR: 196899 Submitted by: Mikael Urankar <mikael.urankar@gmail.com> Reviewed by: arrowd, mat, tcberner Approved by: tcberner (mentor) Differential Revision: https://reviews.freebsd.org/D15674 Changes: head/lang/ghc/Makefile head/lang/ghc/bsd.cabal.mk head/lang/ghc/distinfo head/lang/ghc/files/extra-patch-aclocal.m4 head/lang/ghc/files/patch-configure head/lang/ghc/files/patch-configure.ac head/lang/ghc/files/patch-llvm-targets
Thanks for you contribution, Mikael, and everyone involved.