From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Status of external toolchain support
Date: Thu, 13 May 2010 17:22:02 +0200 [thread overview]
Message-ID: <20100513172202.3c3539f7@surf> (raw)
In-Reply-To: <4BEAE23A.2000906@carallon.com>
Hello,
On Wed, 12 May 2010 18:15:38 +0100
Will Wagner <will_wagner@carallon.com> wrote:
> When configuring buildroot I set all my options the same as the
> toolchain, except for thread support where nptl was not an option. Does
> it matter that they don't match up?
It matters if some packages do depend on these options. The only reason
why we have BR2_INET_RPC, BR2_INET_IPV6 and other similar options in
the external toolchain case is because some packages do depend on them.
As we can't detect their value at menuconfig time, we have to ask the
user to provide the appropriate values according to its toolchain
configuration.
> Should you even be able to set thread library when using an external toolchain?
The thread type (none, linuxthreads, linuxthreads old and nptl) can
already be set from the menuconfig interface in external toolchain mode.
However, the "NPTL" selection isn't visible, as it depends on
BR2_UCLIBC_VERSION_SNAPSHOT. So we should probably :
1. Make BR2_PTHREADS_NATIVE depends on BR2_UCLIBC_VERSION_SNAPSHOT
*OR* BR2_TOOLCHAIN EXTERNAL
2. Improve toolchain/external-toolchain/ext-tool.mk so that it checks
that the value selected for the thread implementation actually
matches the one available in the external toolchain.
> When using crosstools who should build gdb? If buildroot builds it I
> have to make sure my toolchain is not read only? Can I just let
> crosstools build gdb for the host and only get buildroot to make gdb-server?
I always build the cross gdb and gdbserver with crosstool-ng. This is
an area in which I haven't clarified the relation between Buildroot and
the external toolchain.
We should probably :
*) Hide the option to build the cross-gdb in Buildroot in external
toolchain mode, making the assumption that the external toolchain
should provide its own cross gdb.
*) Add an option to ask Buildroot to either build a new gdbserver, or
copy the one available for the external toolchain (so that we are
sure its version matches the version of the cross-gdb in the
external toolchain)
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2010-05-13 15:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 17:15 [Buildroot] Status of external toolchain support Will Wagner
2010-05-12 21:19 ` Yann E. MORIN
2010-05-12 21:34 ` Grant Edwards
2010-05-12 21:53 ` Yann E. MORIN
2010-05-12 22:09 ` Grant Edwards
2010-05-12 21:36 ` Will Wagner
2010-05-12 21:47 ` Yann E. MORIN
2010-05-13 12:29 ` Mark Fisher
2010-05-13 15:22 ` Thomas Petazzoni [this message]
2010-05-13 17:21 ` Yann E. MORIN
2010-05-13 20:08 ` Thomas Petazzoni
2010-05-13 20:26 ` Yann E. MORIN
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=20100513172202.3c3539f7@surf \
--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