From: Waldemar Brodkorb <wbx@uclibc-ng.org>
To: buildroot@busybox.net
Subject: [Buildroot] uClibc-ng
Date: Mon, 21 Jul 2014 18:55:51 +0200 [thread overview]
Message-ID: <20140721165551.GH4431@waldemar-brodkorb.de> (raw)
In-Reply-To: <148124bb-7b66-4363-b171-f0164dab3ced@email.android.com>
Hi Thomas,
Thomas De Schampheleire wrote,
> Hi Waldemar,
>
> Waldemar Brodkorb <wbx@uclibc-ng.org> schreef:
> >Hello Embedded Linux Hackers,
> >
> Interesting development! One question: how do you see musl vs
> uclibc-ng in the future? At this moment uclibc supports more
> architectures, but this may change. Do you think both should/can
> coexist? What are the distinctive features of uclibc over musl,
> according to you?
I think both can coexist for a while. uClibc is more compatible to
glibc, so most of the software packages used on embedded systems are
working fine without patching. Musl is relatively new and there are
patches required to make some stuff work. Alpine Linux, Sabotage and
OpenADK have a lot of patches, fixing musl issues.
uClibc has support for non-MMU systems. uClibc can be configured at
build time and can be made smaller than musl. Musl can be used to
have a complete static linked system, uClibc still requires
libgcc_so.so for some threading functions. uClibc is widely used
in the embedded Linux world, musl is a newcomer.
For musl you need to patch gcc. 4.9.x does not include support for
it.
It is just good to have a choice.
At the time all software packages working fine with musl and support
for it is added to gcc and all architectures and MMU-less systems
are supported, uClibc might be obsolete.
best regards
Waldemar
next prev parent reply other threads:[~2014-07-21 16:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-20 19:13 [Buildroot] uClibc-ng Waldemar Brodkorb
2014-07-20 19:27 ` Thomas De Schampheleire
2014-07-21 16:55 ` Waldemar Brodkorb [this message]
[not found] ` <CA+icZUWU7ApasykCEU=2O_+wNF7=QKP3LBEXLMjHcguwQbOS_g@mail.gmail.com>
2014-07-21 17:51 ` Waldemar Brodkorb
[not found] ` <CAGVrzcZxcgP+yerqW=1ZDrmgiFmOz9eTwFB2KvZ6Xt2MJpbpDA@mail.gmail.com>
2014-07-21 18:42 ` [Buildroot] [OpenWrt-Devel] uClibc-ng Thomas Petazzoni
[not found] ` <CAGVrzcZja2DTrJGA2QWsMH=2GgUBuouSetK+-cUdXY7XbyA8SA@mail.gmail.com>
2014-07-21 19:27 ` Thomas Petazzoni
[not found] ` <A7BE1426-88C8-457E-8FE5-0427CC5B1D72@workware.net.au>
[not found] ` <53CF9F9D.60903@jodybruchon.com>
[not found] ` <14764ab3680.2772.7d831ebe34b31eacf7a4325c447c5923@gmail.com>
2014-07-24 20:48 ` Bernhard Reutner-Fischer
2014-07-21 19:35 ` Waldemar Brodkorb
2014-07-21 19:23 ` Waldemar Brodkorb
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=20140721165551.GH4431@waldemar-brodkorb.de \
--to=wbx@uclibc-ng.org \
--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