[Buildroot] RTLD_DEEPBIND and uClibc

[Thomas Petazzoni]

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