Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] RTLD_DEEPBIND and uClibc
Date: Thu, 17 Jan 2013 09:31:59 +0100	[thread overview]
Message-ID: <20130117093159.2d46ecfd@skate> (raw)
In-Reply-To: <50F74776.60503@petroprogram.com>

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.

> And IMHO those limitations are not really uClibc's fault at all.
> 
> It's because glibc offers stuff like (execinfo.h, mcheck.h,
> RTLD_DEEPBIND etc...) which are not listed in any standard (POSIX or
> otherwise)
> and which people happily use in their own coding projects while being
> unaware that they are not standard comforming
> and hence not easily portable.
> Im sure you noticed this when making that elfutils package Thomas. I
> had as hellish experience as you did when doing
> the initial build of that thing. All because the author of that
> software happened to be Ulrich Drepped, the father of glibc,
> so no wonder that it's code was littered with (non-standard)
> glibc-stuff.

Indeed. And I agree that fixing those compatibility problems in
elfutils is important, because using perf on low-end systems is useful.
However, getting cairo-dock to work with uClibc seems less important to
me, but...

> Also, it's a good learning experience for me while porting stuff to
> uClibc

... of course, for learning purposes, it's always useful!

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-01-17  8:31 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 [this message]
2013-01-17 13:50       ` Stefan Fröberg
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=20130117093159.2d46ecfd@skate \
    --to=thomas.petazzoni@free-electrons.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