From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Status of external toolchain support
Date: Thu, 13 May 2010 22:08:51 +0200 [thread overview]
Message-ID: <20100513220851.6ad92e7e@surf> (raw)
In-Reply-To: <201005131921.50472.yann.morin.1998@anciens.enib.fr>
On Thu, 13 May 2010 19:21:50 +0200
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> wrote:
> > 1. Make BR2_PTHREADS_NATIVE depends on BR2_UCLIBC_VERSION_SNAPSHOT
> > *OR* BR2_TOOLCHAIN EXTERNAL
>
> Not really needed in fact, as what packages really want to know is whether
> the toolchain supports threads or not. The threading model (LinuxThreads
> or native) does not really matter, in fact.
Yeah, in theory, yes. However, I have seen packages such as Webkit that
did compile with a NPTL-powered libc and not with a
linuxthreads-powered libc. See 596bcb63fb26052b86c1271913747e701883dbfa
and https://bugs.busybox.net/show_bug.cgi?id=1405. But, admitted, it's
more a bug in uClibc than a real issue.
> > 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.
>
> With a purely external toolchain, we can't make this assumption sanely.
> So in this case, it's better to keep the option to build cross-gdb (and
> gdbserver).
Why not, but then we should properly handle the case where the
toolchain has a cross-gdb and the user has selected to build one. How
should we handle this ?
> > *) 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)
>
> In the work I'm doing, I'm preparing the fact that cross-gdb + gdbserver
> can be built with crosstool-NG *or* buildroot:
> - if buildroot builds them, then they get disabled in crosstool-NG.
> - if crosstool-NG builds them, then gdbserver is copied to staging/target,
> and the crossgdb is in the toolchain path.
>
> Only the first is currently handled, not the second part.
Yes, this is ok, but even if we're going to add Crosstool-NG as a
backend, I would like to keep the external toolchain support, and thus
improve it to fix those issues.
Regards,
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 20:08 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
2010-05-13 17:21 ` Yann E. MORIN
2010-05-13 20:08 ` Thomas Petazzoni [this message]
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=20100513220851.6ad92e7e@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