mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Brian Wang <brian.wang.0721@gmail.com>
To: musl@lists.openwall.com
Subject: Re: musl for ARM
Date: Wed, 3 Oct 2012 00:18:59 +0800	[thread overview]
Message-ID: <CAPW=hRRuACAsPqgz0h+Mx7koLZsiBDgmSBJMDMUpGSwdBgBtNQ@mail.gmail.com> (raw)
In-Reply-To: <20121002134843.GV254@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

On Oct 2, 2012 9:57 PM, "Rich Felker" <dalias@aerifal.cx> wrote:
>
> On Tue, Oct 02, 2012 at 03:27:28PM +0800, Brian Wang wrote:
> > Hello all,
> >
> > I am currently thinking of switching to musl from glibc for my target
> > after some readings on musl.
> > I would like some advice from musl experts:
> >   * Does it support gettext stuff?
> >   * Does it _boost_ the performance on a 400MHz arm926 device?  Or it
> > is just smaller?
> >     By _boost_, I mean if the user can actually feel the improvement
> > in performance.
>
> In general, if an application's perceived performance varies heavily
> depending on libc, the application is probably doing something wrong
> or at least naive. I can think of some exceptions of course, but this
> advice is just to say that libc is probably not a place to look for
> significantly improving overall performance. If there are libc
> bottlenecks, you could probably get a lot more performance out of
> changing the application.
>
> The main exceptions I can think of are places where libc has the wrong
> big-O: for example, O(n²) qsort or O(nm) strstr, or backtracking
> regex implementations, can make completely-sane programs run extremely
> slow on a bad libc. Note that musl and glibc are almost always
> equivalent in this area; uclibc and dietlibc and perhaps others have
> some problems here.
>
> One area you can get vastly better performance with musl is
> application startup overhead. Especially with static linking, but even
> with dynamic linking if your only .so is libc, the startup time is
> 2-5x faster than glibc, which really makes a difference to the runtime
> of shell scripts (like configure) that invoke tons of external
> programs.

ok.  that makes sense.  the faster application startup time is one of the
performance figure that i'm looking for.

the applications on my device generally run quite smoothly once the are up
thanks to the efl devrlopers :-)

>
> > I did try the musl cross project and successfully built a musl-based
> > arm linux toolchain.
> > My kernel (2.6.24) was built successfully (not tried it on my device
yet).
> > However, when building busybox, there are some header files clashes,
> > resulting in conflicting types.
> > An example of it:
> > ---------------------
> > In file included from
> >
/opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/linux/kd.h:3:0,
> >                  from console-tools/kbd_mode.c:23:
> >
/opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/linux/types.h:12:26:
> > error: conflicting types for ‘fd_set’
> > In file included from
> >
/opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/sys/time.h:9:0,
> >                  from include/libbb.h:45,
> >                  from console-tools/kbd_mode.c:22:
> >
/opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/sys/select.h:25:3:
> > note: previous declaration of ‘fd_set’ was here
> > ---------------------
>
> It looks like these kernel headers are not sanitized for compatibility
> with userspace..?

i built the musl toolchain with the musl cross project found on the musl
community wiki.  i did replace the 3.x kernel with my oldish 2.6.24.  any
pointers on how to sanitize kernel headers?  i have not built toolchains
myself since the days when prebuilt toolchains were readily available...

thanks in advance.

brian

>
> Rich

[-- Attachment #2: Type: text/html, Size: 4251 bytes --]

  reply	other threads:[~2012-10-02 16:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02  7:27 Brian Wang
2012-10-02 10:55 ` John Spencer
2012-10-02 16:05   ` Brian Wang
2012-10-02 13:48 ` Rich Felker
2012-10-02 16:18   ` Brian Wang [this message]
2012-10-02 17:45     ` Rich Felker
2012-10-02 16:39   ` Szabolcs Nagy
2012-10-02 17:46     ` Rich Felker

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='CAPW=hRRuACAsPqgz0h+Mx7koLZsiBDgmSBJMDMUpGSwdBgBtNQ@mail.gmail.com' \
    --to=brian.wang.0721@gmail.com \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).