7 ms·

An introduction to cross compilation with Go

72 points by jemeshsu 14y ago

georgemcbay 14y ago
Very nice introduction. I've been doing Go development for chumby (ARMv5-based) devices for months, and do all of my editing and compilation on Windows and then just rsync the binary over as part of my Sublime Text 2 build script. Go is the greatest embedded-device-style development environment I've ever used, by far, without all the hassles of having to build a full cross-compile toolchain or use some hopelessly out of date vendor-made BSP cross-compile toolchain. (FWIW, building a Go compiler right on the device is easy as well, but even with Go's focus on fast compile times, cross-compiling is still a much better experience when targeting these low CPU/low RAM devices).
- jcr 14y ago
  Cross compiling is certainly necessary and useful for bootstrapping a new platform. It can also be a lot faster to cross compile when the target system is slow, but there is a well known drawback to using cross compiling to speed up development times; you are not stressing the target system, and hence, you've made target-specific bugs harder to find. Of course, there can be substantial costs from slowing down builds and spending development time waiting for compilation on the actual (target) hardware. On the other hand, the advantages of finding target-specific bugs and adequately stressing the system can make the expense worthwhile. Bad hardware happens far more often than vendors like to admit, and stressing the system is a good way to test it. As always, it's a trade-off. The good example of taking the expensive but thorough approach is the OpenBSD project. After getting past bootstrapping an new platform, all builds are done on the actual (target) hardware. Since the code base is cross platform, the new platform could give them the benefit of finding bugs that don't manifest or are unnoticeable on all of the other supported platforms. Also, the OpenBSD project does pretty much continuous build of their tree on actual hardware, so they're always stressing the hardware to make sure it's working properly, as well as finding errant bugs that are tough to find on a single platform.
  - dwc 14y ago
    This only makes sense some of the time, like in your OpenBSD example. Native compile for an embedded app brings much less benefit and significantly more pain.
eckyptang 14y ago
Great article and well timed for me. I've been toying with the idea of trying to bring a Go program up on the following (as I have a couple lying around): https://www.olimex.com/dev/lpc-e2468.html https://www.olimex.com/dev/lpc-e2468.html The only problem is that it doesn't support "normal" linux - uCLinux only.
- 4ad 14y ago
  I did a quick grep of the go tree to search things that are unsuported by uClinux, but I haven't found any. It might just work. edit: the CPU is ARMv4T, the gc Go compilers generate code only for ARMv5 and higher, so it will not work.
  - eckyptang 14y ago
    Thanks much appreciated!! Go's syscall interface looks clean so it wouldn't be too much to deal with either way. I'd be happy with put+get char to start with! I don't mind writing a new backend as the compilers are quite easy to work with by the looks. Plus it'll exercise my brain more than typical CRUD apps.
    - 4ad 14y ago
      The C compiler in the Go tree that's used to compile the C bits of the runtime already supports ARMv4 (unsurprisingly, since it was written a long time ago for Plan 9 and Inferno), only the Go compiler would need modifications. The compiler suite is a pleasure to work on, really clear code, just like all the other code Ken Thompson wrote. Good luck.
      - eckyptang 14y ago
        Even nicer. Thanks for the info. I'll submit results if I get anywhere - might take a month or two :-) Currently trying to a (any) toolchain online first to test the board and get a ucLinux kernel up (gcc cross-compiler + OpenOCD + Olimex ARM-JTAG + ThinkPad Ultrabay parallel port stack should be 'fun').
patrickg 14y ago
I have been using the instructions in the wiki and they work smoothly: http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling

72 points by jemeshsu 14y ago

Very nice introduction. I've been doing Go development for chumby (ARMv5-based) devices for months, and do all of my editing and compilation on Windows and then just rsync the binary over as part of my Sublime Text 2 build script. Go is the greatest embedded-device-style development environment I've ever used, by far, without all the hassles of having to build a full cross-compile toolchain or use some hopelessly out of date vendor-made BSP cross-compile toolchain. (FWIW, building a Go compiler right on the device is easy as well, but even with Go's focus on fast compile times, cross-compiling is still a much better experience when targeting these low CPU/low RAM devices).

jcr 14y ago
Cross compiling is certainly necessary and useful for bootstrapping a new platform. It can also be a lot faster to cross compile when the target system is slow, but there is a well known drawback to using cross compiling to speed up development times; you are not stressing the target system, and hence, you've made target-specific bugs harder to find. Of course, there can be substantial costs from slowing down builds and spending development time waiting for compilation on the actual (target) hardware. On the other hand, the advantages of finding target-specific bugs and adequately stressing the system can make the expense worthwhile. Bad hardware happens far more often than vendors like to admit, and stressing the system is a good way to test it. As always, it's a trade-off. The good example of taking the expensive but thorough approach is the OpenBSD project. After getting past bootstrapping an new platform, all builds are done on the actual (target) hardware. Since the code base is cross platform, the new platform could give them the benefit of finding bugs that don't manifest or are unnoticeable on all of the other supported platforms. Also, the OpenBSD project does pretty much continuous build of their tree on actual hardware, so they're always stressing the hardware to make sure it's working properly, as well as finding errant bugs that are tough to find on a single platform.
- dwc 14y ago
  This only makes sense some of the time, like in your OpenBSD example. Native compile for an embedded app brings much less benefit and significantly more pain.

eckyptang 14y ago

Great article and well timed for me. I've been toying with the idea of trying to bring a Go program up on the following (as I have a couple lying around): https://www.olimex.com/dev/lpc-e2468.html https://www.olimex.com/dev/lpc-e2468.html The only problem is that it doesn't support "normal" linux - uCLinux only.

4ad 14y ago
I did a quick grep of the go tree to search things that are unsuported by uClinux, but I haven't found any. It might just work. edit: the CPU is ARMv4T, the gc Go compilers generate code only for ARMv5 and higher, so it will not work.
- eckyptang 14y ago
  Thanks much appreciated!! Go's syscall interface looks clean so it wouldn't be too much to deal with either way. I'd be happy with put+get char to start with! I don't mind writing a new backend as the compilers are quite easy to work with by the looks. Plus it'll exercise my brain more than typical CRUD apps.
  - 4ad 14y ago
    The C compiler in the Go tree that's used to compile the C bits of the runtime already supports ARMv4 (unsurprisingly, since it was written a long time ago for Plan 9 and Inferno), only the Go compiler would need modifications. The compiler suite is a pleasure to work on, really clear code, just like all the other code Ken Thompson wrote. Good luck.
    - eckyptang 14y ago
      Even nicer. Thanks for the info. I'll submit results if I get anywhere - might take a month or two :-) Currently trying to a (any) toolchain online first to test the board and get a ucLinux kernel up (gcc cross-compiler + OpenOCD + Olimex ARM-JTAG + ThinkPad Ultrabay parallel port stack should be 'fun').

patrickg 14y ago

I have been using the instructions in the wiki and they work smoothly: http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling