Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Report from the Buildroot Meeting in Berlin
Date: Mon, 24 Oct 2016 14:28:40 +0200	[thread overview]
Message-ID: <20161024142840.4c398e72@free-electrons.com> (raw)
In-Reply-To: <b4fb3016-266b-d9bf-bbe1-ec7169c7136a@imgtec.com>

Hello,

On Mon, 24 Oct 2016 13:19:30 +0100, Vicente Olivert Riera wrote:

> Do we want to do that? It looks better and cleaner to have a variable
> that holds flags suitable for building packages but not for building
> kernels/bootloaders. I think that's what Arnout means with the
> TARGET_EXTRA_CFLAGS.
> 
> My question is, if that TARGET_EXTRA_CFLAGS is not added to the wrapper,
> what will happen with those packages that have a crappy build system
> that doesn't respect the env variables?

Well, then they will of course not see the TARGET_EXTRA_CFLAGS. That's
the *whole* point of having the wrapper in the first place: to make
sure a given set of flags gets passed to the compiler, regardless of
the package build system. The very first option for which we added the
wrapper was --sysroot, for external toolchains. If it isn't passed, then
the compiler will not use the Buildroot sysroot.

So of course, if a set of flags is left out of the wrapper, and kept
only in a TARGET_EXTRA_CFLAGS passed in the environment, then those
broken packages will not use such flags.

You can't say at the same time:

 - I don't want those flags encoded in the wrapper, because they break
   the kernel/bootloader build

 - I want those flags encoded in the wrapper, because otherwise broken
   packages will not use them.

> And another question. What happen if we use the real compiler to build
> kernels and bootloaders? Would that be a problem? I don't know other
> architectures, but for MIPS the only variable we need to pass to the
> make program for building a kernel is ARCH=mips. The defconfig will set
> all the rest (float, endian, etc.).

Could be an approach to investigate, but I'm afraid is not as simple as
it looks. "perf" for example is part of the kernel, built with our
cross-compiler, but we would need to go through the wrapper because
"perf" is user-space code, and it does need to link with a bunch of
libraries available in our sysroot (so the --sysroot flag is important).

Perhaps we need an environment variable in the wrapper that tells it
"use all your flags" vs. "use only the flags that are really important,
such as --sysroot". We could then set this environment variable when
building specific packages such as the kernel and bootloaders.

Best regards,

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

  reply	other threads:[~2016-10-24 12:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-19 20:10 [Buildroot] Report from the Buildroot Meeting in Berlin Thomas Petazzoni
2016-10-20 16:39 ` Arnout Vandecappelle
2016-10-21  8:25   ` Thomas Petazzoni
2016-10-21  8:57     ` Arnout Vandecappelle
2016-10-21  9:05       ` Thomas Petazzoni
2016-10-24 12:02   ` Peter Korsgaard
2016-10-24 12:19     ` Vicente Olivert Riera
2016-10-24 12:28       ` Thomas Petazzoni [this message]
2016-10-24 13:05         ` Arnout Vandecappelle
2016-10-24 14:52           ` Vicente Olivert Riera
2016-10-24 14:57             ` Thomas Petazzoni
2016-10-24 15:47               ` [Buildroot] Toolchain wrapper CFLAGS [was: Re: Report from the Buildroot Meeting in Berlin] Arnout Vandecappelle
2016-10-24 12:39       ` [Buildroot] Report from the Buildroot Meeting in Berlin Peter Korsgaard
2016-10-24  0:54 ` Sam Bobroff
2016-10-24  7:25   ` Thomas Petazzoni
2016-10-25  2:21     ` Sam Bobroff

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=20161024142840.4c398e72@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox