From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11813 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.linux.busybox Subject: Re: bbox: musl versus uclibc Date: Mon, 14 Aug 2017 14:48:12 -0400 Message-ID: <20170814184812.GS1627@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1502736523 26972 195.159.176.226 (14 Aug 2017 18:48:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Aug 2017 18:48:43 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: busybox , Felix Fietkau , musl To: Denys Vlasenko Original-X-From: musl-return-11826-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 14 20:48:38 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dhKPh-0006OV-R8 for gllmg-musl@m.gmane.org; Mon, 14 Aug 2017 20:48:33 +0200 Original-Received: (qmail 7765 invoked by uid 550); 14 Aug 2017 18:48:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7744 invoked from network); 14 Aug 2017 18:48:37 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11813 gmane.linux.busybox:44153 Archived-At: On Mon, Aug 14, 2017 at 07:43:39PM +0200, Denys Vlasenko wrote: > As uclibc is increasingly aging, I am finally forced > to switch to musl: I'm bitten by a nasty bug in > getopt() - hush is using it in a slightly unusual way, > which uclibc does not expect. While I'm glad musl is working for you, this sounds fragile unless it's actually just a bug in uclibc, in which case it'll hopefully get fixed. If you're relying on weird internal-state of getopt there's a chance this could break in the future on musl or on other libcs. Can you explain the problem you encountered on uclibc? > I built a toolchain using > https://github.com/richfelker/musl-cross-make > (Rich, is this the thing I should be using?) > and it worked with no issues at all. Yes, it's the easiest and canonical way to get a full toolchain. > (I can probably only wish for the README > to also mention how to make this a _static_ > toolchain... I have a box with 32-bit userspace, > would be awesome to be able to copy this fresh > 64-bit toolchain to it and have it working). If you put LDFLAGS="-static --static" (second form is a hack to workaround libtool's stripping of -static :) in COMMON_CONFIG you should get a static build of the toolchain, but it's linked to whatever the libc in your build environment is. In my config.mak I use: ifeq ($(HOST),) COMMON_CONFIG += CC="i486-linux-musl-gcc -static --static" CXX="i486-linux-musl-g++ -static --static" endif COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os" LDFLAGS="-s -static --static" to build the toolchain static-linked using an existing i486/musl-targeting toolchain. The static in $CC/$CXX is needed because some broken configure tests in GMP try to run test binaries built without honoring LDFLAGS, and will fail to run if you don't have ld-musl-i386 installed. Now that canadian-cross support works, you could probably instead treat i486-linux-musl as a cross compiler (host!=build) instead. If you prefer you can use x86_64 instead, too, but I like the toolchain binaries themselves being 32-bit simply because it saves roughly half the ram usage when running them. > Then I built busybox. Impressions: > > Only a few options did not build: > EXTRA_COMPAT and FEATURE_VI_REGEX_SEARCH > failed because they need GNU regexp extensions. Yes. There was a request for the corresponding version of some of these extensions in the POSIX regex API, which bb vi could be converted to use if we adopted them, but there is some nontrivial runtime cost. It probably doesn't matter now since the regexec core is fairly slow (well, good big-O but bad constant) right now, but it may impose a more noticable relative cost once we make regexec faster. > FEATURE_MOUNT_NFS and FEATURE_INETD_RPC do not build > because they need rpc/rpc.h. > Not complaining, since them being in libc was a mistake > in the first place. I think glibc has dropped these too now, haven't they? AFAIK they're just keeping the symbols for ABI compat but they're not an exposed API for linking new code; you're supposed to use tirpc. > Now, the good news - musl has smaller data! > 6695 bytes versus 7129 bytes for uclibc: > > text data bss dec hex filename > 894902 465 6664 902031 dc38f busybox.uclibc > 912538 563 6132 919233 e06c1 busybox.musl Probably getpw*/getgr* static buffers or something. musl's backend for these just uses the buffer out of getline so as not to impose cost in apps that don't need the legacy (non-_r) functions or an arbitrary limit on record length. It would be interesting to know where the text size increase comes from. Not that big in abs difference, but given that a large portion of the text is busybox code and not libc, it's a fairly large relative difference. Come to think about it, it might actually be regex.. Rich