From: "Stefan Fröberg" <stefan.froberg@petroprogram.com>
To: buildroot@busybox.net
Subject: [Buildroot] RTLD_DEEPBIND and uClibc
Date: Thu, 17 Jan 2013 15:50:20 +0200 [thread overview]
Message-ID: <50F8019C.4000003@petroprogram.com> (raw)
In-Reply-To: <20130117093159.2d46ecfd@skate>
Hi Thomas
17.1.2013 10:31, Thomas Petazzoni kirjoitti:
> Dear Stefan Fr?berg,
>
> On Thu, 17 Jan 2013 02:36:06 +0200, Stefan Fr?berg wrote:
>
>> Well, it's not *that* big.
> It's not that big, but compared it to the size difference between
> uClibc and glibc, and you'll see that switching to glibc is reasonable.
>
> My perception is that uClibc is very relevant for non-MMU systems or
> small systems (having limited quantity of flash/RAM), and on those
> systems, we are not going to run a full-blown X.org stack with a window
> manager and so on.
>
> Whenever you start having X.org on a system and a window manager, most
> likely you have hundreds of megabytes of flash, and therefore, the size
> difference between uClibc and glibc (probably somewhere between 1 and
> 1.5 MB) isn't that much of a problem anymore.
Eh... I think it's more than 1 - 1.5 MB :-)
http://www.etalabs.net/compare_libcs.html
In that comparison it's eglibc (the smaller brother of glibc) vs. other,
more lighter c-libraries.
And even then it's 1.5 MB or more vs uClibc's 336 KB with .a files and 2
MB or more vs. 520 KB.
Even tought in my case, Im targeting to running my system with low-end,
ancient PC desktop's (2000 or earlier),
so it's not really exactly comparable with todays embedded systems, it's
still a huge saving of space when
you start thinking about all the lib's and binaries that go to normal
desktop system.
In a related note, my *full* Live-CD system is now uncompressed to 520
MB (194 MB, if using squashfs xz-compressed image with loopdevice),
and the absolute minimum runtime RAM requirement for starting it
(Xorg,fluxbox, firefox, etc...) is
now about 120 MB (bigger part of that goes to tmp files and other stuff
that are automatically created in initramfs from which it runs directly).
I don't think I could have done that with glibc or eglibc ...
And I haven't even started using GCC 4.7.2 Linktime optimizations yet.
which I expect to cut about 10 - 20 KB per binary away
and finally UPX compression of selected few binaries and libs.
And if even *that* is not enought then I could consider maybe switching
to musl ... maybe ...
So all in all, Im very happy with buildroot and uClibc and not going to
turn back to glibc and bloat
Regards
Stefan
next prev parent reply other threads:[~2013-01-17 13:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-16 12:51 [Buildroot] RTLD_DEEPBIND and uClibc Stefan Fröberg
2013-01-16 23:00 ` Thomas Petazzoni
2013-01-17 0:36 ` Stefan Fröberg
2013-01-17 8:31 ` Thomas Petazzoni
2013-01-17 13:50 ` Stefan Fröberg [this message]
2013-01-17 16:18 ` Alex Bradbury
2013-01-17 16:51 ` Stefan Fröberg
2013-01-17 17:09 ` Alex Bradbury
2013-01-17 18:48 ` Stefan Fröberg
2013-01-17 22:03 ` Peter Korsgaard
2013-01-17 17:44 ` Yann E. MORIN
2013-01-17 18:47 ` Stefan Fröberg
2013-01-17 20:38 ` Yann E. MORIN
2013-01-17 20:41 ` Yann E. MORIN
2013-01-17 20:51 ` Stefan Fröberg
2013-01-17 21:17 ` Yann E. MORIN
2013-01-17 21:23 ` Stefan Fröberg
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=50F8019C.4000003@petroprogram.com \
--to=stefan.froberg@petroprogram.com \
--cc=buildroot@busybox.net \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox