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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to