[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130407154314.GT30576@port70.net>
Date: Sun, 7 Apr 2013 17:43:14 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Building libc separately from libm,librt,libpthread and
others
* John Spencer <maillist-musl@...fooze.de> [2013-04-07 16:52:08 +0200]:
> On 04/07/2013 04:43 PM, Timerlan Moldobaev wrote:
> >Hi,
> >
> >Can you please help with reducing the size of statically linked libc.a
> >library ?
> >Whereas the comparison table located in
> >http://www.etalabs.net/compare_libcs.html
> >claims the size of complete .a set as 333k, I got around 2M while building
> >the library on x86_64 with gcc version 4.1.1.
>
> the comparison page also notes that it is using size(1) and not filesize.
>
compiler flags matter as well: libm has 2x bigger size on gcc 4.4
than on gcc 4.8 because before gcc 4.5 there was no
-fexcess-precision=standard so musl has to use -ffloat-store
for correctness which gives larger and slower code
(this is detected by the configure script)
gcc 4.1 has the same issue and most likely -Os was much worse
back then than in recent gcc
> >I suppose that might be caused by including in libc.a object files that
> >belong to libm, librt, libpthread and others.
> >Am I right ?
> >Is there any way to compile libc.a solely ?
>
> the only thing that can theoretically be left away is libm, but this
> would need some effort.
> things like pthread support are fundamental to musl's inner
> workings, so they can not be left away.
>
you can easily drop src/complex (nothing uses that, you are lucky if it
compiles with 4.1 at all, some ppl reported internal compiler errors on
old gccs in the complex code)
most of src/math can be dropped (all the special functions and those can
be big, but i know that at least frexpl is used by the printf code)
you can drop a lot of functions probably (you have to keep the ones that
are used internally: the 'U' symbols from 'nm libc.a'), but your libc.a
will have reduced functionality for no good reason: if you do static
linking only the used parts will get into the binary (and then the size
of the binary matters not the size of libc.a)
if you only want to compile libc.a you can redefine ALL_LIBS in your
config.mak so it does not contain the SHARED_LIBS (see the Makefile)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
