mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Go in ptxdist
Date: Wed, 5 Oct 2016 15:13:27 +0200	[thread overview]
Message-ID: <20161005131327.mp6qo5gmpzbrt23c@pengutronix.de> (raw)
In-Reply-To: <20161004152325.GA2051@archie.localdomain>

On Tue, Oct 04, 2016 at 05:23:25PM +0200, Clemens Gruber wrote:
> Hi,
> 
> I'd like to start a discussion about implementing support for Go
> language projects in ptxdist. https://golang.org
> 
> The nice thing about the recent Go versions is that cross compilation is
> possible without recompiling Go for the target architecture.
> You can use the Go version from your host and cross compile to the
> supported target architectures and operating system.
> Go binaries are statically compiled, so we would only need Go on the
> host system.
> 
> To cross-compile an ARMv7 binary, you just call:
> env GOOS=linux GOARCH=arm GOARM=7 go build helloworld.go
> Tested with Go 1.7.1 on ArchLinux and cross-compiled binary is running
> successfully on an i.MX6Q.
> If you are wondering about my use case:
> I am implementing a Webapp backend with Revel (github.com/revel/revel)
> for the admin interface to our embedded product and Go is a fine
> language for writing server software.
> 
> --
> 
> What are your thoughts about this?

In PTXdist things should be reproducible. So relying on a compiler for
target code in the host system is not a good idea.
I'm not familiar with Go. Would creating a 'host-go' package be feasible?

> --
> 
> Maybe:
> Having a new FOO_CONF_TOOL value "go" similar to "python3" and adding
> additional case statements to scripts/lib/ptxd_make_world_*.sh and
> building the Go files there, either via go build or using go install.
> 
> We probably need a static mapping from supported toolchain ABIs to
> GOARCH (and GOARM) values:
> aarch64-v8a-linux-gnu       -> GOARCH=arm64
> arm-1136jfs-linux-gnueabi   -> GOARCH=arm GOARM=5

Are you sure that this is correct? The compiler will produce ARMv6 code.

> arm-1136jfs-linux-gnueabihf -> GOARCH=arm GOARM=6
> arm-cortexa8-linux-gnueabi  -> GOARCH=arm GOARM=5

same here.

> arm-cortexa8-linux-gnueabihf-> GOARCH=arm GOARM=7
> arm-v5te-linux-gnueabi      -> GOARCH=arm GOARM=5
> arm-v7a-linux-gnueabi       -> GOARCH=arm GOARM=5

and here.

> arm-v7a-linux-gnueabihf     -> GOARCH=arm GOARM=7

I'd prefer it if we cleaned up the arm architecture stuff in
architecture.in to make this explicit.

> i586-unknown-linux-gnu      -> GOARCH=386
> i686-atom-linux-gnu         -> GOARCH=386
> x86_64-unknown-linux-gnu    -> GOARCH=amd64
> 
> Go supports >=ARMv6 builds with hardfloat only, so I'd fall back to
> building ARMv5 binaries for ARMv6/7 softfloat configurations.

Are you sure this means it cannot create armv6/7 softfloat?

> The mininum size of the generated binaries is still rather large, but
> this will improve in Go 1.8: https://blog.golang.org/go1.7-binary-size
> (At the moment, my hello world example is 927KB if stripped, as it
> includes the statically linked runtime)
> I probably would not use it for small little tools running only for
> short time periods, but for long-running server software, it's fine.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2016-10-05 13:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 15:23 Clemens Gruber
2016-10-05 13:13 ` Michael Olbrich [this message]
2016-10-05 15:55   ` Clemens Gruber
2016-10-05 16:31     ` Michael Olbrich
2016-10-05 20:42       ` Clemens Gruber
2016-10-06  9:17         ` Michael Olbrich
2016-10-07 16:47           ` Clemens Gruber
2016-10-07 18:37             ` Uwe Kleine-König
2016-10-11 16:18               ` Clemens Gruber
2016-10-12  0:07                 ` Clemens Gruber
2016-10-06  6:33     ` Uwe Kleine-König
2016-10-06 10:04       ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161005131327.mp6qo5gmpzbrt23c@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox