Re: Re: [Familiar] Next step in size reduction

From: Matthew Allum <breakfast_at_10.am>
Date: Thu, 2 Jan 2003 21:33:40 +0000

on Thu, Jan 02, 2003 at 05:10:57PM -0500, Alexander Popov wrote:
> I doubt it'll be that easy...
>

Why ?
 
> Please don't get me wrong - I'm a huge fan of uClibc and I made a few great
> final sollutions for my company that use it, but...
> uClibc is really small because it lacks functionality needed by common
> tools/libs that are currently used in Familiar...

Erm I dont think thats quite correct;

Please see http://www.uclibc.org/FAQ.html, Particularly Question 7.

> For example libs like Qt and SDL (probably gtk too) won't work with it -
> the C++ support in uclibc is still quite poor...
>

SDL and GTK compile fine, see http://www.uclibc.org/uClibc-apps.html (
and there not C++, which support for is supposedly pretty good - I try
to avoid it myself ). Even Beasts such as X now compile without
modification.

> I don't think that it's a good idea to replace glibc with uclibc, but I
> sure would love to be able to choose which one to be installed on my PDA.
> This will lead to a distro that more or less will be much different from
> Familiar - everithing should be compiled onece for glibc and once for
> uclibc...
>
> This means ipkgs for Familiar-glibc and ipkgs for Familiar-uclibc!!
>

Would this really be a problem? Im sure people with 16Mb ipaqs
wouldn't think so ;-)

What would be really cool, would be for the event source ipkgs to
support building against glibc or uclibc...

> One last thing: if you have a smaller c library doesn't mean that you'll
> have smaller apps - the difference between uclibc and glibc is usually
> around 400-500K... by building a custom ( with stripped functionality)
> version of glibc you can reduce it with at least 300K so I don't see why
> would you want to use uClibc after all...

Can you back these statements up ?

  -- Matthew
Received on Thu Jan 02 2003 - 21:34:00 EST

This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:19:02 EDT