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] Using a precompiled busybox toolchain as an external toolchain
Date: Tue, 29 Jan 2013 17:08:42 +0100	[thread overview]
Message-ID: <20130129170842.7508fa3f@skate> (raw)
In-Reply-To: <CAKvQZ_0Lc78AXKj-QaxEnchZpfrWsdZ=J_kgookHevnrmZEEhQ@mail.gmail.com>

Dear Willy Lambert,

On Tue, 29 Jan 2013 16:57:56 +0100, Willy Lambert wrote:

> > As I have seen some chat about buildroot toolchain and these problem
> > of relocability, a question arise :
> >
> > Is buildroot toolchain supposed to be maintained in the long run ? Or
> > do you expect people switching more and more on external toolchains ?

Let's make a status of the available toolchain backends:

 * Buildroot internal toolchain backend. This is the historical
   backend. Everything is done by Makefile directly inside Buildroot:
   building binutils, gcc, uClibc, etc. It is limited to uClibc. There
   are discussions since a long time on phasing out this backend in
   favor of the Crosstool-NG backend, but this hasn't happened yet, as
   there are remaining issues to solve with the Crosstool-NG backend. I
   am not sure when/if the internal backend will really go away one day.

 * External toolchain backend. It allows to re-use existing, pre-built,
   toolchains. Those toolchains could have been generated by
   Crosstool-NG, Buildroot, manually, or be provided by a hardware/SoC
   manufacturer. Buildroot really doesn't care here, it simply uses the
   pre-built toolchain as is, and it doesn't build the toolchain.

 * Crosstool-NG backend. In this case, Buildroot builds the toolchain,
   but instead of doing it with internal Makefiles (as done by the
   internal backend described above), it downloads Crosstool-NG,
   installs it, generates a configuration file for it, and triggers the
   build. Once the Crosstool-NG build is done, we are back to the normal
   case where a toolchain is now available, and Buildroot can continue
   its work.

> I will try crosstool-ng. Is this toolchain relocable  ? so I can build
> it first and then take it out of buildroot ?

If you use Crosstool-NG outside of Buildroot, then the toolchain
produced by Crosstool-NG itself is relocatable. This is a raw
toolchain: it has only the C library, C library headers and kernel
headers. No additional libraries.

Then, you can use this pre-build toolchain as an external toolchain in
Buildroot. Buildroot will build additional libraries, and will install
them and their headers in a copy of the toolchain sysroot. In some
sense, the $(O)/host directory of Buildroot becomes a new toolchain,
which contains your pre-built toolchain, and additional libraries and
headers. And this new toolchain (in $(O)/host) is *NOT* relocatable at
the moment, due to various issues: hardcoded paths in .la files, in
<foobar>-config scripts, in the RPATH of the binaries installed in
$(O)/host/usr/bin/, etc.

This is something we intend to fix, but that hasn't happened yet.

Does that clarify the situation?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-01-29 16:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-18 12:42 [Buildroot] Using a precompiled busybox toolchain as an external toolchain Willy Lambert
2012-12-18 12:53 ` Thomas Petazzoni
2012-12-18 15:19   ` Willy Lambert
2012-12-18 15:32     ` Thomas Petazzoni
2012-12-18 16:50       ` Willy Lambert
2012-12-30 12:56         ` Willy Lambert
2012-12-30 13:53           ` Samuel Martin
2013-01-10 23:01             ` Willy Lambert
2013-01-23  8:44             ` Willy Lambert
2013-01-29 15:57               ` Willy Lambert
2013-01-29 16:08                 ` Thomas Petazzoni [this message]
2013-01-29 16:49                   ` Willy Lambert
2013-01-29 17:01                     ` Thomas Petazzoni

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=20130129170842.7508fa3f@skate \
    --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