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 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.