From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3057
Path: news.gmane.org!not-for-mail
From: Timerlan Moldobaev <moldobaev@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Building libc separately from libm,librt,libpthread and others
Date: Sun, 7 Apr 2013 17:43:11 +0300
Message-ID: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a11c26336e2d46d04d9c6565f
X-Trace: ger.gmane.org 1365345802 31456 80.91.229.3 (7 Apr 2013 14:43:22 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 7 Apr 2013 14:43:22 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3061-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 07 16:43:26 2013
Return-path: <musl-return-3061-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3061-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UOqoV-0002dO-C0
	for gllmg-musl@plane.gmane.org; Sun, 07 Apr 2013 16:43:23 +0200
Original-Received: (qmail 13413 invoked by uid 550); 7 Apr 2013 14:43:22 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 13405 invoked from network); 7 Apr 2013 14:43:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:date:message-id:subject:from:to
         :content-type;
        bh=csut9oZ/QCmqQkM1K24V6ZsqkPWLc3ztzQf84Babrjg=;
        b=glXhEQ5Vz6Eg/d5BQY2sCqJXjL6eu+DxxsbPHFf9Z1RBeDq8eCN4XQEw/uh9vxup8M
         pq4s9FJSJ4FWol/i64tKZpdwauBtuLdGkgq4MuToE5DbWMbzmXhQDm4MkU7FX7UnA/bj
         Zle1rsD8nAjGEV01SU2xxPn+x1Ezok3EaGK2RBQVWvbt/MYT+WPeV1eGJSZWvYdClbyS
         rMUSG+AyyCDNQhUiXiw0ajD2NY80rprMeZNK5CusGXDX/L1SA5mHxxXBBoGWOnfpS59F
         Edu1ely4dwu4nvhEkXBjQShdstTVIvL+GqGGfQ9qLVAfiYwCDLv1CG5rWThaC1xZHfuX
         mwGw==
X-Received: by 10.180.185.176 with SMTP id fd16mr8065311wic.31.1365345791298;
 Sun, 07 Apr 2013 07:43:11 -0700 (PDT)
Xref: news.gmane.org gmane.linux.lib.musl.general:3057
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3057>

--001a11c26336e2d46d04d9c6565f
Content-Type: text/plain; charset=ISO-8859-1

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.
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 ?

Thanks,
Tim.

--001a11c26336e2d46d04d9c6565f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>Can you please help with=
 reducing the size of statically linked libc.a library ?</div><div>Whereas =
the comparison table located in <a href=3D"http://www.etalabs.net/compare_l=
ibcs.html">http://www.etalabs.net/compare_libcs.html</a> =A0</div>
<div>claims the size of complete .a set as 333k, I got around 2M while buil=
ding the library on x86_64 with gcc version 4.1.1.</div><div>I suppose that=
 might be caused by including in libc.a =A0object files that belong to libm=
, librt, libpthread and others.</div>
<div>Am I right ?=A0</div><div>Is there any way to compile libc.a solely ?<=
/div><div><br></div><div>Thanks,</div><div>Tim.</div><div style><br></div><=
div style><br></div></div>

--001a11c26336e2d46d04d9c6565f--


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3058
Path: news.gmane.org!not-for-mail
From: John Spencer <maillist-musl@barfooze.de>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and
 others
Date: Sun, 07 Apr 2013 16:52:08 +0200
Message-ID: <51618818.9080002@barfooze.de>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: ger.gmane.org 1365346350 4414 80.91.229.3 (7 Apr 2013 14:52:30 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 7 Apr 2013 14:52:30 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3062-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 07 16:52:33 2013
Return-path: <musl-return-3062-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3062-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UOqxL-0006W4-3D
	for gllmg-musl@plane.gmane.org; Sun, 07 Apr 2013 16:52:31 +0200
Original-Received: (qmail 16368 invoked by uid 550); 7 Apr 2013 14:52:30 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 16360 invoked from network); 7 Apr 2013 14:52:30 -0000
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0
In-Reply-To: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Xref: news.gmane.org gmane.linux.lib.musl.general:3058
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3058>

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.

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




From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3060
Path: news.gmane.org!not-for-mail
From: Szabolcs Nagy <nsz@port70.net>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and
 others
Date: Sun, 7 Apr 2013 17:43:14 +0200
Message-ID: <20130407154314.GT30576@port70.net>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
 <51618818.9080002@barfooze.de>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ger.gmane.org 1365349403 31428 80.91.229.3 (7 Apr 2013 15:43:23 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 7 Apr 2013 15:43:23 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3064-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 07 17:43:27 2013
Return-path: <musl-return-3064-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3064-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UOrkc-0007B2-BU
	for gllmg-musl@plane.gmane.org; Sun, 07 Apr 2013 17:43:26 +0200
Original-Received: (qmail 30358 invoked by uid 550); 7 Apr 2013 15:43:25 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 30350 invoked from network); 7 Apr 2013 15:43:25 -0000
Content-Disposition: inline
In-Reply-To: <51618818.9080002@barfooze.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Xref: news.gmane.org gmane.linux.lib.musl.general:3060
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3060>

* John Spencer <maillist-musl@barfooze.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)


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3061
Path: news.gmane.org!not-for-mail
From: John Spencer <maillist-musl@barfooze.de>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and
 others
Date: Sun, 07 Apr 2013 18:04:47 +0200
Message-ID: <5161991F.408@barfooze.de>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com> <51618818.9080002@barfooze.de> <20130407154314.GT30576@port70.net>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: ger.gmane.org 1365350709 10907 80.91.229.3 (7 Apr 2013 16:05:09 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 7 Apr 2013 16:05:09 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3065-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 07 18:05:13 2013
Return-path: <musl-return-3065-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3065-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UOs5f-0005jT-2i
	for gllmg-musl@plane.gmane.org; Sun, 07 Apr 2013 18:05:11 +0200
Original-Received: (qmail 15383 invoked by uid 550); 7 Apr 2013 16:05:09 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 15375 invoked from network); 7 Apr 2013 16:05:09 -0000
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0
In-Reply-To: <20130407154314.GT30576@port70.net>
Xref: news.gmane.org gmane.linux.lib.musl.general:3061
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3061>

On 04/07/2013 05:43 PM, Szabolcs Nagy wrote:
> * John Spencer<maillist-musl@barfooze.de>  [2013-04-07 16:52:08 +0200]:
>
>> On 04/07/2013 04:43 PM, Timerlan Moldobaev wrote:
>>
>>> 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)

musl compiles fine with gcc 3.4.6 and gcc 4.2.4 (used by sabotage for 
stage0 bootstrap - gcc 4.2.4 is only used on arm though)

>
> 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)

the official way to do this is ./configure --disable-shared



From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3062
Path: news.gmane.org!not-for-mail
From: Szabolcs Nagy <nsz@port70.net>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and
 others
Date: Sun, 7 Apr 2013 18:21:10 +0200
Message-ID: <20130407162109.GU30576@port70.net>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ger.gmane.org 1365351680 20768 80.91.229.3 (7 Apr 2013 16:21:20 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 7 Apr 2013 16:21:20 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3066-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 07 18:21:24 2013
Return-path: <musl-return-3066-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3066-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UOsLK-0003D7-82
	for gllmg-musl@plane.gmane.org; Sun, 07 Apr 2013 18:21:22 +0200
Original-Received: (qmail 27972 invoked by uid 550); 7 Apr 2013 16:21:21 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 27963 invoked from network); 7 Apr 2013 16:21:21 -0000
Content-Disposition: inline
In-Reply-To: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Xref: news.gmane.org gmane.linux.lib.musl.general:3062
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3062>

* Timerlan Moldobaev <moldobaev@gmail.com> [2013-04-07 17:43:11 +0300]:
> 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.

btw the comparision was made on i386 and
32bit vs 64bit can make a big difference

i just checked here and libc.a is 1.4M but
the real size of the object code is 338K using
size libc.a |awk '{s+=$4}END{print s/1024}'
(i386, gcc 4.8)


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3063
Path: news.gmane.org!not-for-mail
From: Rich Felker <dalias@aerifal.cx>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and
 others
Date: Sun, 7 Apr 2013 23:32:23 -0400
Message-ID: <20130408033223.GJ20323@brightrain.aerifal.cx>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ger.gmane.org 1365406357 20714 80.91.229.3 (8 Apr 2013 07:32:37 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 07:32:37 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3067-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 09:32:41 2013
Return-path: <musl-return-3067-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3067-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UP6ZE-0002Vs-Lz
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 09:32:41 +0200
Original-Received: (qmail 23822 invoked by uid 550); 8 Apr 2013 03:32:37 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 23811 invoked from network); 8 Apr 2013 03:32:37 -0000
Content-Disposition: inline
In-Reply-To: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Xref: news.gmane.org gmane.linux.lib.musl.general:3063
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3063>

On Sun, Apr 07, 2013 at 05:43:11PM +0300, 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.
> 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 ?

What is your goal in getting it smaller? With static linking, only the
object files needed by a program end up in the resulting binary, so
compiling less will not make your binaries any smaller. The only
benefits I can think of are (1) reducing time to compile musl, and (2)
storing the development files on an extremely small storage device. If
you tell us what you're trying to do, we can offer better advice on
how to meet your needs.

Rich


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3070
Path: news.gmane.org!not-for-mail
From: nwmcsween@gmail.com
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and others
Date: Sun, 7 Apr 2013 20:47:59 -0700
Message-ID: <F833E121-11B4-45C0-9F7C-D061B149CFD9@gmail.com>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0 (1.0)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-3BED65C1-4A91-467F-9E3B-9CA72548B591
Content-Transfer-Encoding: 7bit
X-Trace: ger.gmane.org 1365441299 14771 80.91.229.3 (8 Apr 2013 17:14:59 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 17:14:59 +0000 (UTC)
To: "musl@lists.openwall.com" <musl@lists.openwall.com>
Original-X-From: musl-return-3068-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 19:15:03 2013
Return-path: <musl-return-3068-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3068-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UPFem-0003zR-8b
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 19:15:00 +0200
Original-Received: (qmail 1341 invoked by uid 550); 8 Apr 2013 03:48:18 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 1333 invoked from network); 8 Apr 2013 03:48:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:subject:references:from:content-type:x-mailer
         :in-reply-to:message-id:date:to:content-transfer-encoding
         :mime-version;
        bh=u7eIzENFc+Vt8+0uo7xpf14cSUzjEQQk4xWCXyntlMk=;
        b=yNR5OPCQUtB2yR6bQxW/4e6eBU7x3eCkVGSaLBP3Cyyr6qoOJ2BwGKy7rW3VZuI/+G
         AC8Af/U45Jcz1ZsFp7MdVryCosdXU4CKUzOUMREWsVGzVwyvRyZ0D79ScU+jh2T0vNmh
         YPmEhem403MiKe2fQQAPIUPIuJs2IrvAy2QIlezEyNf6GSG9fArOAs1q1CdCd/sdz4VP
         iFp+tg+zyLFGLsgYdpeuNeuUgfsHMiomwJGR4r4wbDVe50FBNvE4cQNpGfXYmO2UDR9T
         swOBhPlEcLVV8Q0XQtwOSrz3nOIRYSYB3uC4VAKGNpU/gTfQ4qsLPNFd89Jh8EUjXs/n
         0krw==
X-Received: by 10.50.51.226 with SMTP id n2mr5797679igo.25.1365392886028;
        Sun, 07 Apr 2013 20:48:06 -0700 (PDT)
X-Mailer: iPhone Mail (10B144)
In-Reply-To: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
Xref: news.gmane.org gmane.linux.lib.musl.general:3070
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3070>


--Apple-Mail-3BED65C1-4A91-467F-9E3B-9CA72548B591
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Musl is a posix + iso c standard library, there is no separation of standard=
s..

On Apr 7, 2013, at 7:43 AM, Timerlan Moldobaev <moldobaev@gmail.com> wrote:

> Hi,
>=20
> Can you please help with reducing the size of statically linked libc.a lib=
rary ?
> Whereas the comparison table located in http://www.etalabs.net/compare_lib=
cs.html =20
> 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.
> I suppose that might be caused by including in libc.a  object files that b=
elong to libm, librt, libpthread and others.
> Am I right ?=20
> Is there any way to compile libc.a solely ?
>=20
> Thanks,
> Tim.
>=20
>=20

--Apple-Mail-3BED65C1-4A91-467F-9E3B-9CA72548B591
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Musl is a posix + iso c standard library, there is no separation of standards..</div><div><br>On Apr 7, 2013, at 7:43 AM, Timerlan Moldobaev &lt;<a href="mailto:moldobaev@gmail.com">moldobaev@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Hi,</div><div><br></div><div>Can you please help with reducing the size of statically linked libc.a library ?</div><div>Whereas the comparison table located in <a href="http://www.etalabs.net/compare_libcs.html">http://www.etalabs.net/compare_libcs.html</a> &nbsp;</div>
<div>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.</div><div>I suppose that might be caused by including in libc.a &nbsp;object files that belong to libm, librt, libpthread and others.</div>
<div>Am I right ?&nbsp;</div><div>Is there any way to compile libc.a solely ?</div><div><br></div><div>Thanks,</div><div>Tim.</div><div style=""><br></div><div style=""><br></div></div>
</div></blockquote></body></html>
--Apple-Mail-3BED65C1-4A91-467F-9E3B-9CA72548B591--


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3066
Path: news.gmane.org!not-for-mail
From: Timerlan Moldobaev <moldobaev@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and others
Date: Mon, 8 Apr 2013 10:43:25 +0300
Message-ID: <CAM2CaF+EKieGBuLRFAjTxtf5mrbWnVh60A8ROFqzm4JFGyTVLw@mail.gmail.com>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
	<51618818.9080002@barfooze.de>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=14dae9cdbef1951a7e04d9d497c4
X-Trace: ger.gmane.org 1365438432 28428 80.91.229.3 (8 Apr 2013 16:27:12 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 16:27:12 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3070-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 18:27:16 2013
Return-path: <musl-return-3070-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3070-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UPEuT-0007T6-Fg
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 18:27:09 +0200
Original-Received: (qmail 5635 invoked by uid 550); 8 Apr 2013 14:40:28 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 11612 invoked from network); 8 Apr 2013 07:43:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        bh=Os1jW5EuRAJqWo42LoZp4moXJ7yfn3unv6Lj+5dr4Eg=;
        b=h4QwA/wDr79ULd9bFuOrV3UHj6auoXc79VOxABoW2MhwdbdKWwmklHYxFsMrMfOkvx
         S7z7/bXcga2r/S9Rbmko4YyQstX6aTbGO61ZHnJ9lsHPCcGyLB+sD6Os56RK76q5xUaT
         n4nX40wCo6/pGlcy0CGvRG/ajxcCQl2v4sDCh4y+vdl1t3XwkAhnFf+SwkRdtB75k2uw
         4BaP3zwg4rPjaippJb2lv4TgjohbESzN9qFgxLAqlpvNM0xS3k+rXwWifTkqlmc41v1/
         +npV7a1RNzFxIJJWjsYefSG50QZYmYA+ibFy4i350f+TsIwiQFoIC3lZwbzs0v7zgz9B
         7TQA==
X-Received: by 10.220.231.199 with SMTP id jr7mr14809420vcb.70.1365407006252;
 Mon, 08 Apr 2013 00:43:26 -0700 (PDT)
Original-Sender: boris.alesker@gmail.com
In-Reply-To: <51618818.9080002@barfooze.de>
X-Google-Sender-Auth: GDretF6Dl9qhqYHSeao_FW5qaug
Xref: news.gmane.org gmane.linux.lib.musl.general:3066
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3066>

--14dae9cdbef1951a7e04d9d497c4
Content-Type: text/plain; charset=ISO-8859-1

John , thank you for pointing out that size()  is used in the comparison
table, somehow oversaw that.
BTW, out of curiosity where does the extra size come from ? Some elf
specific format data ?


On Sun, Apr 7, 2013 at 5:52 PM, John Spencer <maillist-musl@barfooze.de>wrote:

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

--14dae9cdbef1951a7e04d9d497c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">John , thank you for pointing out that size() =A0is used i=
n the comparison table, somehow oversaw that.=A0<div style>BTW, out of curi=
osity where does the extra size come from ? Some elf specific format data ?=
=A0</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,=
 Apr 7, 2013 at 5:52 PM, John Spencer <span dir=3D"ltr">&lt;<a href=3D"mail=
to:maillist-musl@barfooze.de" target=3D"_blank">maillist-musl@barfooze.de</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 04/07/2013 04:43 PM, Ti=
merlan Moldobaev wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Can you please help with reducing the size of statically linked libc.a<br>
library ?<br>
Whereas the comparison table located in<br>
<a href=3D"http://www.etalabs.net/compare_libcs.html" target=3D"_blank">htt=
p://www.etalabs.net/<u></u>compare_libcs.html</a><br>
claims the size of complete .a set as 333k, I got around 2M while building<=
br>
the library on x86_64 with gcc version 4.1.1.<br>
</blockquote>
<br></div>
the comparison page also notes that it is using size(1) and not filesize.<d=
iv class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I suppose that might be caused by including in libc.a =A0object files that<=
br>
belong to libm, librt, libpthread and others.<br>
Am I right ?<br>
Is there any way to compile libc.a solely ?<br>
</blockquote>
<br></div>
the only thing that can theoretically be left away is libm, but this would =
need some effort.<br>
things like pthread support are fundamental to musl&#39;s inner workings, s=
o they can not be left away.<br>
<br>
<br>
</blockquote></div><br></div>

--14dae9cdbef1951a7e04d9d497c4--


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3067
Path: news.gmane.org!not-for-mail
From: Timerlan Moldobaev <moldobaev@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and others
Date: Mon, 8 Apr 2013 11:31:43 +0300
Message-ID: <CAM2CaFLmz5TWDBSeBTWKapH9cD3wBKvvLUXsViz-w-1h7ZJhMQ@mail.gmail.com>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
	<20130408033223.GJ20323@brightrain.aerifal.cx>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a11c3851642782204d9d5442c
X-Trace: ger.gmane.org 1365438445 28724 80.91.229.3 (8 Apr 2013 16:27:25 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 16:27:25 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3071-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 18:27:29 2013
Return-path: <musl-return-3071-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3071-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UPEuh-0007p5-34
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 18:27:23 +0200
Original-Received: (qmail 5812 invoked by uid 550); 8 Apr 2013 14:40:41 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 13525 invoked from network); 8 Apr 2013 08:31:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        bh=MSyLed/XU075ybd41eLcWT5wab3QlVD67AnrXys9Lcc=;
        b=WNdu4RKTzB3lTnG0Fh9qdMqwzwjNMqukwE8zU8HbrQctj9paHIQCR3S53oWSZe72bQ
         TTXWPGyQgCoNTlC930TjoAkOO+bUGky+As++J60FmMoGzkYc2n/PyqwkQiEYNJGlL4Ch
         Gp1BNajrikSU3KGgyqpBDT5eecEu1e5VPwlwdT88s9JcJ4SpV9RLijyCSFfzo5dKOdzt
         9hv/KBweH99SnVOp8oe0+Oj83UmaPXcoFzBDV02eV2yEe/rxYmmlO5vmT5HhuS5Cg+XE
         iRnwhfSTOuGBROWvPReUgjnCkWFIovV/xaPBdfZc/jLZmNMTnbZXvjZ9zxzPtbupZf3V
         nG5A==
X-Received: by 10.112.199.230 with SMTP id jn6mr613726lbc.131.1365409903309;
 Mon, 08 Apr 2013 01:31:43 -0700 (PDT)
Original-Sender: boris.alesker@gmail.com
In-Reply-To: <20130408033223.GJ20323@brightrain.aerifal.cx>
X-Google-Sender-Auth: 9ylujoY_EimbM2Eu5-iV7BfY_Bo
Xref: news.gmane.org gmane.linux.lib.musl.general:3067
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3067>

--001a11c3851642782204d9d5442c
Content-Type: text/plain; charset=ISO-8859-1

Well, the intention is to use musl package with possible source code
modifications and platform specific optimizations as a an implementation
for standard c library. These sources will be visible to 3rd party
developers wishing to use libc services.  This is the opportunity to make
sure that MIT license allows to do that.
As the developers have the freedom to use any compiler /linker they want,
can I  assume that only the required parts of the libc.a objects will be
included in the resulting executable ?


On Mon, Apr 8, 2013 at 6:32 AM, Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Apr 07, 2013 at 05:43:11PM +0300, 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.
> > 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 ?
>
> What is your goal in getting it smaller? With static linking, only the
> object files needed by a program end up in the resulting binary, so
> compiling less will not make your binaries any smaller. The only
> benefits I can think of are (1) reducing time to compile musl, and (2)
> storing the development files on an extremely small storage device. If
> you tell us what you're trying to do, we can offer better advice on
> how to meet your needs.
>
> Rich
>

--001a11c3851642782204d9d5442c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Well, the=A0intention=A0is to use musl package with p=
ossible source code modifications and platform specific optimizations as a =
an implementation for standard c library. These sources will be visible to =
3rd party developers wishing to use libc services. =A0This is the opportuni=
ty to make sure that MIT license allows to do that.=A0<br>
</div><div style>As the developers have the freedom to use any compiler /li=
nker they want, can I =A0assume that only the required parts of the libc.a =
objects will be included in the resulting=A0executable=A0?=A0</div></div><d=
iv class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Mon, Apr 8, 2013 at 6:32 AM, Rich Fel=
ker <span dir=3D"ltr">&lt;<a href=3D"mailto:dalias@aerifal.cx" target=3D"_b=
lank">dalias@aerifal.cx</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Sun, Apr 07, <a href=3D"tel:2013=
" value=3D"+9722013">2013</a> at 05:43:11PM +0300, Timerlan Moldobaev wrote=
:<br>
&gt; Hi,<br>
&gt;<br>
&gt; Can you please help with reducing the size of statically linked libc.a=
<br>
&gt; library ?<br>
&gt; Whereas the comparison table located in<br>
&gt; <a href=3D"http://www.etalabs.net/compare_libcs.html" target=3D"_blank=
">http://www.etalabs.net/compare_libcs.html</a><br>
&gt; claims the size of complete .a set as 333k, I got around 2M while buil=
ding<br>
&gt; the library on x86_64 with gcc version 4.1.1.<br>
&gt; I suppose that might be caused by including in libc.a =A0object files =
that<br>
&gt; belong to libm, librt, libpthread and others.<br>
&gt; Am I right ?<br>
&gt; Is there any way to compile libc.a solely ?<br>
<br>
</div></div>What is your goal in getting it smaller? With static linking, o=
nly the<br>
object files needed by a program end up in the resulting binary, so<br>
compiling less will not make your binaries any smaller. The only<br>
benefits I can think of are (1) reducing time to compile musl, and (2)<br>
storing the development files on an extremely small storage device. If<br>
you tell us what you&#39;re trying to do, we can offer better advice on<br>
how to meet your needs.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Rich<br>
</font></span></blockquote></div><br></div>

--001a11c3851642782204d9d5442c--


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3068
Path: news.gmane.org!not-for-mail
From: Boris Alesker <boris.alesker@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and others
Date: Mon, 8 Apr 2013 15:48:59 +0300
Message-ID: <CAM2CaFJx6AYSPtE5UW9KFa-SN0DX3bRE1NczT8XsC4+TdzAxqA@mail.gmail.com>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
	<20130408033223.GJ20323@brightrain.aerifal.cx>
	<CAM2CaFLmz5TWDBSeBTWKapH9cD3wBKvvLUXsViz-w-1h7ZJhMQ@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a11c28c1058812004d9d8dc83
X-Trace: ger.gmane.org 1365438467 29045 80.91.229.3 (8 Apr 2013 16:27:47 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 16:27:47 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3073-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 18:27:49 2013
Return-path: <musl-return-3073-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3073-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UPEuv-0008Dq-23
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 18:27:37 +0200
Original-Received: (qmail 6120 invoked by uid 550); 8 Apr 2013 14:40:55 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 9551 invoked from network); 8 Apr 2013 12:49:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:in-reply-to:references:date:message-id
         :subject:from:to:content-type;
        bh=YpZK7aXgxetuNsbidmaYT6jRWGhWjkOMiaAXbT4M6k0=;
        b=Dc89x91xQE79hSE2iNjKLVFBqsWZh56fsugsDTgBXg7O2eGRsjLSce8v65mneL7s2+
         +WjwA/Gfx0t122eQj7TtZ7aPdRw3Ccj4S/1EvelagGs3AmA7XsXE4LAnmCEoJLvmXVPr
         1SZ3cAbm1Ilvr3tMpHV7VeuXlBW0AAALq8yUUtltB8QlJuYSwvF6nuvspS7F/z2iGYTI
         7czLRsBP+KB9k7kkCtwjXv7X35KSGkWv0k6AoeefsUx/Cq/uZyjDhJNZXS4xdkTojbC9
         zEd3uP4lbDx+BhZUGYN29qfUpCdAet5Qttr2jMPBeP/vf9bvHE7X2v+COIUXAzTQzN2B
         Fe8w==
X-Received: by 10.152.45.37 with SMTP id j5mr1042908lam.9.1365425339791; Mon,
 08 Apr 2013 05:48:59 -0700 (PDT)
In-Reply-To: <CAM2CaFLmz5TWDBSeBTWKapH9cD3wBKvvLUXsViz-w-1h7ZJhMQ@mail.gmail.com>
Xref: news.gmane.org gmane.linux.lib.musl.general:3068
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3068>

--001a11c28c1058812004d9d8dc83
Content-Type: text/plain; charset=ISO-8859-1

John Spencer maillist-musl@barfooze.de> wrote:

> the comparison page also notes that it is using size(1) and not filesize.

John , thank you for pointing out that size()  is used for
measurements  in the comparison table, somehow oversaw that.
BTW, out of curiosity where does the extra size come from ? Some elf
specific format data ?

--001a11c28c1058812004d9d8dc83
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><pre style=3D"white-space:pre-wrap"><span name=3D"John Spe=
ncer" class=3D"" style=3D"font-size:12.800000190734863px;font-family:arial,=
sans-serif">John Spencer</span><span style=3D"font-size:12.800000190734863p=
x;font-family:arial,sans-serif;white-space:nowrap">=A0</span><span class=3D=
"" style=3D"font-size:12.800000190734863px;font-family:arial,sans-serif;whi=
te-space:nowrap"><a href=3D"mailto:maillist-musl@barfooze.de">maillist-musl=
@barfooze.de</a></span>&gt; wrote:</pre>
<pre style=3D"white-space:pre-wrap">&gt; the comparison page also notes tha=
t it is using size(1) and not filesize.</pre><pre><font face=3D"arial, sans=
-serif"><span style=3D"white-space:normal">John , thank you for pointing ou=
t that size() =A0is used for =A0measurements=A0 in the comparison table, so=
mehow oversaw that.=A0</span></font><div style=3D"white-space:normal;font-f=
amily:arial,sans-serif;font-size:12.800000190734863px">
BTW, out of curiosity where does the extra size come from ? Some elf specif=
ic format data ?=A0</div></pre></div>

--001a11c28c1058812004d9d8dc83--


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3069
Path: news.gmane.org!not-for-mail
From: Boris Alesker <boris.alesker@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and others
Date: Mon, 8 Apr 2013 15:54:04 +0300
Message-ID: <CAM2CaFLhqFTh9FkvaSehmwQ+7JLnohX9Qs8nWkv2UikRcBbH_w@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a11c38516833f2604d9d8ee9d
X-Trace: ger.gmane.org 1365438469 29103 80.91.229.3 (8 Apr 2013 16:27:49 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 16:27:49 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3072-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 18:27:52 2013
Return-path: <musl-return-3072-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3072-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UPEus-00083p-6d
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 18:27:34 +0200
Original-Received: (qmail 5963 invoked by uid 550); 8 Apr 2013 14:40:52 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 11565 invoked from network); 8 Apr 2013 12:54:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:date:message-id:subject:from:to
         :content-type;
        bh=FMG26xFQlavAhW+n90aUiStDC3EOWTfiPm3PG90n5LY=;
        b=1JH8AUtEsUAqBNK2VPqJu7UU6MshdxgUZXMNAY3t/7cIuP2rsjsLiAui/zTzZfB0AM
         cJMSzXS+lUOc7KSy6OyqMOJxV4phFNDEkmufEmzSjrLtFpHEKm2DSXCVA8YSMwy8qehk
         XpecVIwJ8oUXSUtGIlPLGDZhqBLKhQaAJVStJC/VjXPfbNPnGPINa6JqWpUA0e0RRkMh
         RcbrcDHkaet91hQgbWthwOX49aKwfoHGjMEhY1ME9eDPBtpUXAkLLQo+1zarZsHudLYJ
         baH2yrdxnVBv1A0pg/1ro5rMcq9pRetEUZ/YDtC91t+054yhj/VJfSZc1wiV/dNuaDf4
         U2Cw==
X-Received: by 10.112.199.230 with SMTP id jn6mr1066532lbc.131.1365425644583;
 Mon, 08 Apr 2013 05:54:04 -0700 (PDT)
Xref: news.gmane.org gmane.linux.lib.musl.general:3069
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3069>

--001a11c38516833f2604d9d8ee9d
Content-Type: text/plain; charset=ISO-8859-1

Rich Felker dalias@aerifal.cx wote:

>What is your goal in getting it smaller? With static linking, only the
> object files needed by a program end up in the resulting binary, so
> compiling less will not make your binaries any smaller. The only
> benefits I can think of are (1) reducing time to compile musl, and (2)
> storing the development files on an extremely small storage device. If
> you tell us what you're trying to do, we can offer better advice on
> how to meet your needs.


Well, the intention is to use musl package with possible source code
modifications and platform specific optimizations as an implementation for
standard c library. These sources will be visible to 3rd party developers
wishing to use libc services.
1. This is the opportunity to ask  whether  MIT license allows to do that.
2. As the developers have the freedom to use any compiler /linker they
want, can I  assume that only the required parts of the libc.a objects will
be included in the resulting executable ?

--001a11c38516833f2604d9d8ee9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div><table cellpadding=3D"0" class=3D"" style=3D"font=
-family:arial,sans-serif;font-size:12.800000190734863px"><tbody><tr class=
=3D""><td class=3D"" style=3D"width:466.3999938964844px"><table cellpadding=
=3D"0" class=3D"" style=3D"width:466.3999938964844px">
<tbody><tr><td><div class=3D""><span name=3D"Rich Felker" class=3D"" style=
=3D"font-size:12.800000190734863px">Rich Felker</span>=A0<span class=3D""><=
a href=3D"mailto:dalias@aerifal.cx">dalias@aerifal.cx</a> wote:</span></div=
><div class=3D"">
<span class=3D""><br></span></div>&gt;What is your goal in getting it small=
er? With static linking, only the<br>&gt; object files needed by a program =
end up in the resulting binary, so<br>&gt; compiling less will not make you=
r binaries any smaller. The only<br>
&gt; benefits I can think of are (1) reducing time to compile musl, and (2)=
<br>&gt; storing the development files on an extremely small storage device=
. If<br>&gt; you tell us what you&#39;re trying to do, we can offer better =
advice on<br>
<div class=3D""><span class=3D"">&gt; how to meet your needs.=A0</span></di=
v><div class=3D""><span class=3D""><br></span></div><div class=3D""><span c=
lass=3D""><br></span></div><div class=3D""><span class=3D""><div>Well, the=
=A0intention=A0is to use musl package with possible source code modificatio=
ns and platform specific optimizations as an implementation for standard c =
library. These sources will be visible to 3rd party developers wishing to u=
se libc services.=A0</div>
<div>1. This is the opportunity to ask =A0whether=A0=A0MIT license allows t=
o do that.=A0<br></div><div>2. As the developers have the freedom to use an=
y compiler /linker they want, can I =A0assume that only the required parts =
of the libc.a objects will be included in the resulting=A0executable=A0?=A0=
</div>
</span></div><div class=3D""><span class=3D""><br></span></div></td></tr></=
tbody></table></td></tr></tbody></table></div></div>

--001a11c38516833f2604d9d8ee9d--


From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3064
Path: news.gmane.org!not-for-mail
From: Rich Felker <dalias@aerifal.cx>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: Building libc separately from libm,librt,libpthread and
 others
Date: Mon, 8 Apr 2013 11:43:55 -0400
Message-ID: <20130408154355.GP20323@brightrain.aerifal.cx>
References: <CAE+eE2KPijbLym0Hv3RH2ub+ALzTL=m4vR+PS8Amo6SjYCRTPA@mail.gmail.com>
 <51618818.9080002@barfooze.de>
 <CAM2CaF+EKieGBuLRFAjTxtf5mrbWnVh60A8ROFqzm4JFGyTVLw@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ger.gmane.org 1365437451 9959 80.91.229.3 (8 Apr 2013 16:10:51 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 8 Apr 2013 16:10:51 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-3074-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 08 18:10:55 2013
Return-path: <musl-return-3074-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-3074-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1UPEef-0008ED-Ox
	for gllmg-musl@plane.gmane.org; Mon, 08 Apr 2013 18:10:50 +0200
Original-Received: (qmail 7768 invoked by uid 550); 8 Apr 2013 15:44:08 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 7758 invoked from network); 8 Apr 2013 15:44:07 -0000
Content-Disposition: inline
In-Reply-To: <CAM2CaF+EKieGBuLRFAjTxtf5mrbWnVh60A8ROFqzm4JFGyTVLw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Xref: news.gmane.org gmane.linux.lib.musl.general:3064
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/3064>

On Mon, Apr 08, 2013 at 10:43:25AM +0300, Timerlan Moldobaev wrote:
> John , thank you for pointing out that size()  is used in the comparison
> table, somehow oversaw that.
> BTW, out of curiosity where does the extra size come from ? Some elf
> specific format data ?

A .o file contains a lot of information beyond code: it has to have
all the symbols defined or referenced in the file, as well as the
relocations for both symbolic references and addresses of objects
defined in the same file. Even with a very efficient object format
like the old a.out format, this additional data is likely to be nearly
as large as or larger than an object file containing a single function
or just a few small functions. ELF's storage of this additional data
is much more general/flexible, but also much less efficient; often
it's several times as big as the code. In a worst case, it's hundreds
of times larger (e.g. if the code is just a single "ret" instruction).

The reason I use size(1) rather than file size to measure static
library size is twofold:

1. The size of the actual code and data, not the size of the .o files
in the .a file, is what actually ends up in your final binary.
Actually if you don't strip the binary, some of the additional
information (symbols, etc.) will end up in the final binary too, but
it's proportionally much smaller since it's just one set of tables for
the whole binary rather than one set for each translation unit.

2. Any metric based on .a file size rather than size(1) will "reward"
implementations that are poorly-factored and thus yield larger static
binaries. The easiest way to make your .a file look smaller is to
merge lots of source files together. This indeed reduces the size of
the .a file, but the cost is that programs which use one function from
the .a file will be forced to pull in several other functions they may
not need.

Due to misc. costs of having lots of .o files (build time for musl
itself, excess file size of the .a file, etc.) I've actually merged
some functions into common files. The usual criteria for such merging
are that the functions each be tiny/trivial and not likely to be
useful in tiny applications.

Rich