All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Analysis of build results for 2016-05-16
Date: Tue, 17 May 2016 21:34:07 +0200	[thread overview]
Message-ID: <20160517213407.7d47b4a3@free-electrons.com> (raw)
In-Reply-To: <1463511367.5420.26.camel@infradead.org>

Hello,

On Tue, 17 May 2016 11:56:07 -0700, Geoff Levand wrote:

> On Tue, 2016-05-17 at 15:36 +0200, Thomas Petazzoni wrote:
> >       x86_64 |                 flannel-v0.5.5 | NOK | http://autobuild.buildroot.net/results/6664189a6f3a815978e8d0a1d7ef408ca47e2874/
> > 
> > Geoff, can you look into this one?  
> 
> I believe I have the fix for this one in my patch 'package/go: Build
> special host binaries'.  This is a reworked version of what I posted
> last time.

OK.

> > >          arm |                  host-go-1.6.2 | NOK | http://autobuild.buildroot.net/results/42a8d07101d8d954511d1c884ecb66e8d861899e/  
> > 
> > error: #warning requested reentrant code
> > 
> > Geoff, in fact it seems like host-go itself needs thread support in the
> > target toolchain to build properly, so our plan to have only the Go
> > packages depend on BR2_TOOLCHAIN_HAS_THREADS does not work.  
> 
> Yes, the solution I came up with is that the go target package must

By "go target package", you mean a target package that is written in
Go, and not specifically the package/go/ package (which doesn't have a
target variant), right?

> specify BR2_TOOLCHAIN_HAS_THREADS if it uses cgo support.  If
> BR2_TOOLCHAIN_HAS_THREADS is set, then host-go sets CGO_ENABLED=1 and
> builds a compiler with cgo support.  If BR2_TOOLCHAIN_HAS_THREADS is
> not set, then host-go does not build in cgo support.  The two cases:
> 
> A go package which does not use cgo sets BR2_TOOLCHAIN_HAS_THREADS=n,

A package cannot *set* BR2_TOOLCHAIN_HAS_THREADS.
BR2_TOOLCHAIN_HAS_THREADS is a property of the toolchain.

> the host-go is not build with cgo support.  Both the target package
> and host-go should build OK since no thread support is needed.
> 
> A package that uses cgo sets BR2_TOOLCHAIN_HAS_THREADS=y, host-go
> is build with cgo support.  Both build OK since the toolchain has
> thread support.

What needs to happen instead is the following (and is quite similar to
what you said, except for the interaction with
BR2_TOOLCHAIN_HAS_THREADS=y) :

 *) The host-go package will build cgo support when
    BR2_TOOLCHAIN_HAS_THREADS=y and otherwise not build cgo support.

 *) Any target package that is written in Go and that needs cgo support
    should have a "depends on BR2_TOOLCHAIN_HAS_THREADS" in its
    dependencies.

This needs to be explained by a comment in package/go/go.mk, as it is
not trivial.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2016-05-17 19:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17  6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2016-05-16 Thomas Petazzoni
2016-05-17 13:36 ` [Buildroot] Analysis of build " Thomas Petazzoni
2016-05-17 13:53   ` Rodrigo Rebello
2016-05-17 15:13   ` gwenhael.goavec
2016-05-17 15:20     ` Thomas Petazzoni
2016-05-18  7:09       ` gwenhael.goavec
2016-05-18 19:40         ` Arnout Vandecappelle
2016-05-18 21:54           ` Thomas Petazzoni
2016-05-18 22:15             ` Arnout Vandecappelle
2016-05-17 16:27   ` Bernd Kuhls
2016-05-17 18:47   ` Bernd Kuhls
2016-05-17 18:56   ` Geoff Levand
2016-05-17 19:34     ` Thomas Petazzoni [this message]
2016-05-17 20:15       ` Geoff Levand
2016-05-17 21:03   ` Yegor Yefremov
2016-05-17 21:06     ` Yegor Yefremov
2016-05-18 19:33   ` Samuel Martin
2016-05-19 13:26   ` Gustavo Zacarias
2016-05-19 18:52   ` Gustavo Zacarias
2016-05-19 21:31     ` Arnout Vandecappelle
2016-05-20  7:35       ` Thomas Petazzoni
2016-05-25 14:44   ` Clayton Shotwell
2016-06-17  1:21   ` Ben Boeckel
2016-06-17  2:11     ` Ben Boeckel

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=20160517213407.7d47b4a3@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.