I was able to compile Haskell for a mips-linux-musl target ( https://onion.io/omega). Most problems were due to the different architecture (MIPS) than musl. Once you have a C cross-compiler (I used http://crosstool-ng.org/ to built the cross-compiler toolchain), compiling GHC as a cross compiler for that target and then a Haskell application shouldn't be a problem. If you have enough disk space on the target, I would suggest that you compile your Haskell application into a static binary. On Sat, Apr 9, 2016 at 10:47 AM Lana Black wrote:

You will probably have better luck using ghc with musl‎.

Check out this thread: ‎ https://mail.haskell.org/pipermail/haskell-cafe/2015-May/119843.html

Original Message From: Patrick Pelletier Sent: Saturday, April 9, 2016 7:54 AM To: haskell-cafe Subject: [Haskell-cafe] Haskell on OpenWRT

Has anyone had any success running Haskell programs on OpenWRT?

Specifically, I'm running OpenWRT on x86_64, so processor architecture shouldn't be an issue. However, by default OpenWRT uses musl as its C library, so binaries from a "normal" Linux system wouldn't be compatible with OpenWRT.

I attempted to get around this problem by building an OpenWRT image with glibc as the C library. In theory, that ought to solve the problem. In practice, my program (a simple hello-world type program, which runs fine on Ubuntu) hung, printing nothing, using nearly all of one core, and was unkillable by any signal other than SIGKILL. If left alone to run, it eventually used all available memory and then died.

I took a look at ldd, to see if there were any clues there. On my Ubuntu 12.04 machine, where I compiled the program (using ghc 7.4.1), I get:

ppelletier@patrick64:~/programming/haskell$ ldd contact linux-vdso.so.1 => (0x00007fff36f50000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f8d49cf8000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f8d49af0000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8d497f3000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8d495eb000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8d493e7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d49028000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8d48e0b000) /lib64/ld-linux-x86-64.so.2 (0x00007f8d49f8d000)

On my OpenWRT (trunk) box, I get:

root@OpenWrt:~# ldd /tmp/contact linux-vdso.so.1 (0x00007ffd2afcc000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f27a057a000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f27a0373000) libm.so.6 => /lib/libm.so.6 (0x00007f27a0080000) librt.so.1 => /lib/librt.so.1 (0x00007f279fe79000) libdl.so.2 => /lib/libdl.so.2 (0x00007f279fc76000) libc.so.6 => /lib/libc.so.6 (0x00007f279f906000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f279f6f4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f279f4d9000) /lib64/ld-linux-x86-64.so.2 (0x00007f27a07dc000)

This is almost the same, except it has "libgcc_s.so.1", while on the Ubuntu box it does not.

I'd welcome any ideas on how to solve (or at least diagnose) this problem. I'd also be interested in any thoughts on the broader question of running Haskell programs on OpenWRT.

Thanks,

--Patrick

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Mac OS X as the host is unbelievably painful. It's easier to have the host and target be the same OS (linux + linux). You don't need a full system (gentoo) to use GHC + musl in static linking mode. Just an appropriate cross-compiler toolchain. crosstools-ng can be configured so that the compiler always produces a static build (run ct-ng menuconfig, and look through the options. The UI should be familiar if you've ever used the Linux kernel menuconfig facility). On Sun, Apr 10, 2016 at 9:57 PM Patrick Pelletier wrote:

Thanks! I'll take a look at building a cross-compiler, since it worked out for you. I'd been a little afraid to try. (I previously had a bad experience building ghc as a cross-compiler, but that was with Android as the target and Mac OS X as the host. The issues I encountered were mostly when it tried to link ELF binaries with the Mach-O linker, or vice versa. But with both host and target being Linux, the linker issues can probably be swept under the rug.)

The C cross compiler shouldn't be a problem, since OpenWRT's "buildroot" builds a cross-compiler automatically. (Though if for any reason that turns out to be a problem, thanks for the tip about crosstool-ng.) Ideally, I'd love to integrate ghc into OpenWRT's buildroot so that packages written in Haskell could be built as easily and in the same way as packages written in C. But I still have a lot to learn before I attempt that.

My boot device is an SD card, so space for static binaries shouldn't be a problem. I already have several gigabytes, which should be more than enough, and if for some reason I needed more space, I could swap in a larger SD card, or add more space via USB or mSATA.

I was aware of Marios Titas's "GHC + musl = easier static linking", but wasn't really thrilled at the idea of needing an install of Gentoo-musl to host it. (But I can certainly try that if I have to.) Or I could just use my OpenWRT box to host the GHC-musl, but I'm running into issues with getting gcc to run on the target, which I'm currently following up with the OpenWRT community.

Thanks for the ideas! I'm sure that one way or another I'll be able to get it working.

--Patrick

On 4/10/16 8:40 AM, Tomas Carnecky wrote:

I was able to compile Haskell for a mips-linux-musl target ( https://onion.io/omega). Most problems were due to the different architecture (MIPS) than musl. Once you have a C cross-compiler (I used http://crosstool-ng.org/http://crosstool-ng.org/ to built the cross-compiler toolchain), compiling GHC as a cross compiler for that target and then a Haskell application shouldn't be a problem.

If you have enough disk space on the target, I would suggest that you compile your Haskell application into a static binary.

On Sat, Apr 9, 2016 at 10:47 AM Lana Black wrote:

...

You will probably have better luck using ghc with musl‎.

Check out this thread: ‎ https://mail.haskell.org/pipermail/haskell-cafe/2015-May/119843.html

Original Message From: Patrick Pelletier Sent: Saturday, April 9, 2016 7:54 AM To: haskell-cafe Subject: [Haskell-cafe] Haskell on OpenWRT

Has anyone had any success running Haskell programs on OpenWRT?

Specifically, I'm running OpenWRT on x86_64, so processor architecture shouldn't be an issue. However, by default OpenWRT uses musl as its C library, so binaries from a "normal" Linux system wouldn't be compatible with OpenWRT.

I attempted to get around this problem by building an OpenWRT image with glibc as the C library. In theory, that ought to solve the problem. In practice, my program (a simple hello-world type program, which runs fine on Ubuntu) hung, printing nothing, using nearly all of one core, and was unkillable by any signal other than SIGKILL. If left alone to run, it eventually used all available memory and then died.

I took a look at ldd, to see if there were any clues there. On my Ubuntu 12.04 machine, where I compiled the program (using ghc 7.4.1), I get:

ppelletier@patrick64:~/programming/haskell$ ldd contact linux-vdso.so.1 => (0x00007fff36f50000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f8d49cf8000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f8d49af0000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8d497f3000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8d495eb000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8d493e7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d49028000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8d48e0b000) /lib64/ld-linux-x86-64.so.2 (0x00007f8d49f8d000)

On my OpenWRT (trunk) box, I get:

root@OpenWrt:~# ldd /tmp/contact linux-vdso.so.1 (0x00007ffd2afcc000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f27a057a000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f27a0373000) libm.so.6 => /lib/libm.so.6 (0x00007f27a0080000) librt.so.1 => /lib/librt.so.1 (0x00007f279fe79000) libdl.so.2 => /lib/libdl.so.2 (0x00007f279fc76000) libc.so.6 => /lib/libc.so.6 (0x00007f279f906000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f279f6f4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f279f4d9000) /lib64/ld-linux-x86-64.so.2 (0x00007f27a07dc000)

This is almost the same, except it has "libgcc_s.so.1", while on the Ubuntu box it does not.

I'd welcome any ideas on how to solve (or at least diagnose) this problem. I'd also be interested in any thoughts on the broader question of running Haskell programs on OpenWRT.

Thanks,

--Patrick

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 4/10/16 1:03 PM, Tomas Carnecky wrote:

crosstools-ng can be configured so that the compiler always produces a static build (run ct-ng menuconfig, and look through the options. The UI should be familiar if you've ever used the Linux kernel menuconfig facility).

I decided to try your approach, but I'm running into a few problems. First, where in the UI is the option to make the compiler produce a static build? Under "Toolchain Options", there is an option to link the toolchain itself statically, but that's not the same thing. I've gone through all the menus, and can't find anything else about static linking. Second, what libraries did you have to build for the target before you could get ghc to compile? I've been trying to build the ghc cross-compiler, but ghc seems to insist on having ncurses on the target. So now I've gone down the rabbit hole of building ncurses for the target. Currently the build of ncurses is failing with: x86_64-unknown-linux-musl-gcc -DHAVE_CONFIG_H -I. -I../include -DNDEBUG -O2 --param max-inline-insns-single=1200 -c ../ncurses/lib_gen.c -o ../objects/lib_gen.o In file included from ./curses.priv.h:325:0, from ../ncurses/lib_gen.c:19: _20591.c:843:15: error: expected ')' before 'int' ../include/curses.h:1631:56: note: in definition of macro 'mouse_trafo' #define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen) ^ make[1]: *** [../objects/lib_gen.o] Error 1 make[1]: Leaving directory `/home/ppelletier/src/ncurses-6.0/ncurses' make: *** [all] Error 2 I'm sure I can figure it out, but I'm worried about how many more libraries might be needed in addition to ncurses. Did you just have to slog through all of this, or am I doing something wrong? Thanks, --Patrick

On 4/12/16 11:54 AM, Tomas Carnecky wrote:

ncurses is the only library.

Not sure how I managed to configure the crosscompiler to produce static binaries, maybe it was an option which I had to pass to GHC. In any case, here's a docker image which includes instructions how I build the cross compiler: https://github.com/wereHamster/onion-omega/tree/master/xt, and here's a docker image which builds on top of that to compile a cross-compiling GHC: https://github.com/wereHamster/onion-omega/tree/master/ghc.

Thanks for all your help! I now have my ghc cross-compiler working, and I can run simple programs on the OpenWRT box! However, in order to build nontrivial programs, I need cabal. The GHC cross-compiling page ( https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling ) recommends: cabal --with-ghc=<cross-ghc> --with-ld=<ld> ... So I expanded this approach to: alias mcabal="cabal --with-ghc=x86_64-unknown-linux-musl-ghc --with-ld=x86_64-unknown-linux-musl-ld --with-gcc=x86_64-unknown-linux-musl-gcc --with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg --disable-executable-dynamic" Am I on the right track with that approach? I'm able to install some packages with mcabal. (For example, "mcabal install hourglass".) But with cryptonite, I get: ppelletier@patrick64:~/src/lifx/lifx-programs$ mcabal install --flags=-integer-gmp cryptonite Resolving dependencies... Configuring memory-0.12... Building memory-0.12... Preprocessing library memory-0.12... running dist/dist-sandbox-5f352b7e/build/Data/Memory/MemMap/Posix_hsc_make failed (exit code 127) command was: dist/dist-sandbox-5f352b7e/build/Data/Memory/MemMap/Posix_hsc_make

dist/dist-sandbox-5f352b7e/build/Data/Memory/MemMap/Posix.hs Failed to install memory-0.12 cabal: Error: some packages failed to install: cryptonite-0.15 depends on memory-0.12 which failed to install. memory-0.12 failed during the building phase. The exception was: ExitFailure 1

I haven't been able to figure out exactly what's going on there. Or, "mcabal install aeson" fails with: Building aeson-0.11.1.4... Preprocessing library aeson-0.11.1.4... ghc: Data/Aeson/TH.hs:9:14-28: Template Haskell requires GHC with interpreter support Perhaps you are using a stage-1 compiler? Usage: For basic information, try the `--help' option. Failed to install aeson-0.11.1.4 cabal: Error: some packages failed to install: aeson-0.11.1.4 failed during the building phase. The exception was: ExitFailure 1 Is there a way to get Template Haskell to work? Or is that just impossible? (And therefore, cross-compiling is impossible for many of the packages on Hackage?) Is this a sign that I should have taken Lana's suggestion to use Marios's approach instead? --Patrick