From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] Experimental addition of the newlib library
Date: Thu, 24 Sep 2015 23:30:33 +0200 [thread overview]
Message-ID: <87fv23o686.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20150915213924.62547101@free-electrons.com> (Thomas Petazzoni's message of "Tue, 15 Sep 2015 21:39:24 +0200")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
Sorry for the slow response, I've been away and busy with deadlines at
$WORK.
>> However, I'm not sure it is possible to run newlib as the C library
>> under Linux (i.e. as a replacement for glibc/uClibc/musl). IIRC, newlib
>> really targets kernel-less systems. It seems there are linux support
>> files in the newlib source, but I doubt tht is often tested or even
>> compeltely supported; a cursory look at the interwebs does not return
>> promissing results...
>>
>> And in nay case, I'm afraid a lot of packages would not build against
>> newlib.
>>
>> All that to say that I need to look at the patch, and I otherwise do not
>> see the point for having newlib in Buildroot...
> Chris is the person who submitted the support for the NuttX operating
> system, which is another operating system kernel than Linux. In this
> context, newlib is the C library of choice.
> Now, there is indeed the question of how to handle all the existing
> packages that would anyway only build with a normal Linux C library.
> It's an open debate.
> Maybe we first need to get an agreement on whether we want to merge
> something such a newlib toolchain support and NuttX support. On my
> side, I believe I am quite favorable to that, but I was also favorable
> to Luca's patch series on the mdev stuff without devtmpfs, which is why
> Luca started working on this, but in the end, it got turned down.
I wouldn't call it "getting turned down", I simply wanted to make it
clear that just working around old kernels in mdev wouldn't fix the
various other packages that haven't ever been tested on such ancient
kernels, and for the mdev issue a simpler fix would just be to backport
devtmpfs support to the kernel.
I must say that my initial thought when seeing the newlib patches was
that this was really outside the scope of Buildroot, but the patches ARE
quite small and self contained, so if there is interest it might make
sense after all.
I does require that we basically stick the entire package/ under an
ifndef NEWLIB (and system / fs / linux as well), and it will stay a
lower priority than the normal Linux stuff, but if that can be done
at a high enough level then that is probably ok.
I recently bought one of those cheap arduino clones with a stm32f103
(m3) for tinkering, so I might even use it myself! ;)
--
Venlig hilsen,
Peter Korsgaard
next prev parent reply other threads:[~2015-09-24 21:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 7:02 [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Chris Wardman
2015-09-13 7:02 ` [Buildroot] [PATCH 2/3] New entry for the Cortex-M4 processor Chris Wardman
2015-09-13 8:21 ` Thomas Petazzoni
2015-09-15 20:52 ` Yann E. MORIN
2015-09-24 21:02 ` Peter Korsgaard
2015-09-13 7:02 ` [Buildroot] [PATCH 3/3] Adding support for uclibcpp library Chris Wardman
2015-09-13 22:00 ` Thomas Petazzoni
2015-09-17 7:07 ` Cjw X
2015-09-17 7:25 ` Thomas Petazzoni
2015-09-13 8:17 ` [Buildroot] [PATCH 1/3] Experimental addition of the newlib library Thomas Petazzoni
2015-09-15 4:06 ` Cjw X
2015-09-15 7:35 ` Thomas Petazzoni
2015-09-15 17:53 ` Yann E. MORIN
2015-09-15 19:39 ` Thomas Petazzoni
2015-09-24 21:30 ` Peter Korsgaard [this message]
2015-09-25 7:30 ` Thomas Petazzoni
2015-09-27 16:40 ` Cjw X
2015-09-15 20:45 ` Yann E. MORIN
[not found] ` <CAOudHSVLKiTwrkv0xBNVW=ry3w1yOv4TJqP8+JMFSJRzw3dASQ@mail.gmail.com>
2015-09-16 17:07 ` Yann E. MORIN
2015-09-16 17:36 ` Cjw X
2015-09-16 17:38 ` Thomas Petazzoni
2015-09-15 20:41 ` Yann E. MORIN
2015-09-17 7:41 ` Cjw X
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=87fv23o686.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.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