[OpenWrt-Devel] [PATCH] toolchain/uClibc: add support of uClibc-ng

Adam Kuklycz adamk at mcservices.com.au
Wed Aug 26 19:48:58 EDT 2015


Hi all,

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

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.

Cheers
Adam


On 27/08/15 04:28, Alexey Brodkin wrote:
> Hi John,
>
> On Wed, 2015-08-26 at 20:20 +0200, John Crispin wrote:
>> Hi,
>>
>> 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
>>> 0.9.33.2
>>>
>> 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.
>
> -Alexey
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list