Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] package/go: fix building host go toolchain when target isn't supported
Date: Wed, 17 Apr 2019 09:02:43 +0200	[thread overview]
Message-ID: <20190417090243.64dec40e@windsurf> (raw)
In-Reply-To: <20190415204951.18744-1-arnout@mind.be>

Hello,

On Mon, 15 Apr 2019 22:49:51 +0200
"Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> wrote:

> From: Anisse Astier <anisse@astier.eu>
> 
> The go toolchain can cross-compile by default. So most of the time,
> building a toolchain that supports a target, allows us to also build go
> binaries for the host. This is how support for host go packages was
> added: we use the same toolchain that was initially built only for
> target.
> 
> But we might want to build a go binary for the host, when compiling a
> target for which go isn't supported. Then, building host-go will fail:
> by default, we build go for a specific target, and give the toolchain
> bootstrap scripts the cross compiler we'll use.
> 
> This change modifies this behaviour: we only assume the go toolchain is
> cross-capable if we know the current target is supported. Otherwise this
> is a simple host go tool. We don't need to set any of the options needed
> for cross-compilation in that case.
> 
> Thus, only set all the target-specific go options under a condition that
> the target arch is supported. The only option we still set is
> HOST_GO_CGO_ENABLED, and we always set it to enabled.

I have applied to master, but I do have a question related to
HOST_GO_CGO_ENABLED. Right now, we have the following:

if Go supports target architecture
	if target supports thread
		HOST_GO_CGO_ENABLED=1
	else
		HOST_GO_CGO_ENABLED=0
else
	HOST_GO_CGO_ENABLED=1
endif

What is a bit strange here is that if you build for a target that isn't
supported by Go, you always get CGO support in the host go. However, if
the target is support by Go, but thread support is not available, you
don't have CGO support in the host go.

I.e when compiling host go programs, the availability of CGO depends on
whether the target is supported + has threads, which is a bit weird.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      parent reply	other threads:[~2019-04-17  7:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15 20:49 [Buildroot] [PATCH v2] package/go: fix building host go toolchain when target isn't supported Arnout Vandecappelle
2019-04-16 15:48 ` Anisse Astier
2019-04-17  7:02 ` Thomas Petazzoni [this message]

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=20190417090243.64dec40e@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /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