[OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng
adamk at mcservices.com.au
Wed Aug 26 19:48:58 EDT 2015
I was wondering why OpenWRT switched to musl -- is it purely because
uclibc hasn't actually maintained their code properly?
One of the things I have noticed since the CC trunk builds I did with
kernel 3.18.11 + uclibc is that the image sizes have ballooned out by a
For example, a build on trunk r45705 which uses uclibc and kernel
3.18.11 would allow for most features to be included in a build e.g.
openvpn, luci + ssl support, more connecting protocols than just pppoe
and so on with a router sporting 8MB of flash.
Now with recent trunk builds, with musl and kernel 4.1.x, I've had to
cut features considerably just to make it fit. Just adding openvpn with
openssl support means that an image prior that built at 7MB would
balloon out to 8MB which would mean that the image would not be produced
as it is too big.
I've yet to do a separate build with latest trunk and uclibc but
certainly something has caused image build sizes to grow quite a bit
recently, though in testing I've done at least, it hasn't impacted on
router performance for now.
On 27/08/15 04:28, Alexey Brodkin wrote:
> Hi John,
> On Wed, 2015-08-26 at 20:20 +0200, John Crispin wrote:
>> On 26/08/2015 20:11, Alexey Brodkin wrote:
>>> uClibc-ng is a spin-off of original uClibc, see http://www.uclibc-ng.org/
>>> We try to regularly add changes from uClibc to uClibc-ng.
>>> We even sent patches and bug reports to the uClibc mailing list.
>>> The config file is compatible between uClibc-ng 1.0 and uClibc git master.
>>> This might change in the future.
>>> Our main goal is to provide regularly a stable and tested release
>>> to make embedded system developers happy.
>>> The main advantage of uClibc-ng over olde good uClibc is regular releases
>>> so there's no need to keep tons of patches on top of years old
>> why do you not use musl ? it is actively support rather than being
>> hooked on life support.
> The point is I'm about to submit patch with support of new architecture (ARC)
> in OpenWRT. And unfortunately the only libc we have now is uClibc.
> And since "original" uClibc lack recent releases (where ARC support might exist
> as we're in uclibc's master branch for quite some time already) I went forward
> with uClibc-ng which sees releases much more often and in released tarballs
> we already have support of ARC.
> So I understand that other architectures may not benefit a lot from newer
> uClibc but for us (ARC) there's no other way.
> Hope that makes sense.
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel