glibc vs. newlib

glibc vs. newlib

[Darin.Johnson]

What are the experiences and tradeoffs of using newlib vs. glibc?  I'm targetting 16M board (maybe some 8M), no swap space, and I'm concerned that adding glibc will suck much of this up.  At the same time we'd also like to be able to use off-the-shelf components like dhcpd or telnetd, and are not sure if newlib would give us too many headaches there.

Darin Johnson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Gary D. Thomas]

On Fri, 2003-04-04 at 16:08, Darin.Johnson@nokia.com wrote:
>
> What are the experiences and tradeoffs of using newlib vs. glibc?  I'm targetting 16M board (maybe some 8M), no swap space, and I'm concerned that adding glibc will suck much of this up.  At the same time we'd also like to be able to use off-the-shelf components like dhcpd or telnetd, and are not sure if newlib would give us too many headaches there.

newlib doesn't really have everything you'd want.  You might
look into uclibc or dietlibc as a lighter weight library.

--
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Wolfgang Denk]

In message <F0B628F30F48064289D8CCC1EE21B7A80C4869@mvebe001.americas.nokia.com> you wrote:
>
> What are the experiences and tradeoffs of using newlib vs. glibc?  I'm targetting 16M board (maybe some 8M), no swap space, and I'm concerned that adding glibc will suck much of this up.  At the same time we'd also like to be able to use off-the-shelf c
> omponents like dhcpd or telnetd, and are not sure if newlib would give us too many headaches there.

newlib is probably not sufficient for any practical purposes.

OTOH 16 MB of RAM are sufficient to even run GCC on  the  target,  so
woth  a  bit of careful tuning a LOT can be done using plain glibc. I
recommend to start with glibc; if you;re running out of space try  to
optimize it, and only when this fails start looking for alternatives.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Mark Hatle]

Darin.Johnson@nokia.com wrote:
> What are the experiences and tradeoffs of using newlib vs. glibc?  I'm targetting 16M board (maybe some 8M), no swap space, and I'm concerned that adding glibc will suck much of this up.  At the same time we'd also like to be able to use off-the-shelf components like dhcpd or telnetd, and are not sure if newlib would give us too many headaches there.
>
> Darin Johnson

I strongly recommend you stay away from newlib.

My recommendation is to use glibc "optimized"  (there are numerous programs that
will re-link glibc based on particular requirements you may have.)

Or if you need a more "generic solution" look into uclibc.

--Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Erik Christiansen]

On Fri, Apr 04, 2003 at 07:30:21PM -0600, Mark Hatle wrote:
> I strongly recommend you stay away from newlib.

Mark,

   Is it something related to linux that has given you a bad experience
   with newlib? (There is no related information in your post, so I'm
   curious.)

   We are using newlib on a bare-bones ppc board, with every success.
   We've trialled the library in both dynamically relocatable form, and
   statically linked.

   An exerpt from the cross-gcc FAQ helps clarify when you might use it:
>>>
   Licensing
      Glibc is covered by the LGPL (the GNU Library General Public License).
   Newlib is a collection of software from several sources, each with their own
   copyrights, but basically it's a Berkeley style copyright.

   Resource Utilization
      Glibc, being intended for native Unix environments, does not need to worry
   about memory usage as much. It is designed to work most efficiently in
   demand-page-loaded shared library situations. Newlib, being intended for
   embedded systems, does worry about memory usage (and is more memory-efficient
   than glibc).
<<<

Regards,
Erik


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Mark Hatle]

Erik Christiansen wrote:
> On Fri, Apr 04, 2003 at 07:30:21PM -0600, Mark Hatle wrote:
>
>>I strongly recommend you stay away from newlib.
>
>
> Mark,
>
>    Is it something related to linux that has given you a bad experience
>    with newlib? (There is no related information in your post, so I'm
>    curious.)
>

In my experience, the only thing newlib is useful for is bootstrapping a system.
  If you have a working system with newlib, more power to you.  I have never had
any success or desire to get that to work.  For a small system libc, uclibc
looks promising.  For a more traditional linux system, glibc is truely the only
way to do it.  (With special tools you can dramatically reduce the size of
glibc, but not as far as most people would like.)

--Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Marius Groeger]

On Mon, 7 Apr 2003, Mark Hatle wrote:

> looks promising.  For a more traditional linux system, glibc is
> truely the only way to do it.  (With special tools you can
> dramatically reduce the size of glibc, but not as far as most people
> would like.)

This kind of size reduction (aka. "optimisation") sounds sort of scary
to me. Glibc is a big and complicated beast (look, for instance, at
the rather loose ties by which the libnss-stuff is held together). You
seem to have some experience here. Can you seriously recommend this
for _production_ software?

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Mark Hatle]

Marius Groeger wrote:
> On Mon, 7 Apr 2003, Mark Hatle wrote:
>
>
>>looks promising.  For a more traditional linux system, glibc is
>>truely the only way to do it.  (With special tools you can
>>dramatically reduce the size of glibc, but not as far as most people
>>would like.)
>
>
> This kind of size reduction (aka. "optimisation") sounds sort of scary
> to me. Glibc is a big and complicated beast (look, for instance, at
> the rather loose ties by which the libnss-stuff is held together). You
> seem to have some experience here. Can you seriously recommend this
> for _production_ software?

Absolutly.  The optimizations that are supported in both open source and by
companies like the one I work for (MontaVista Software) are pretty simple.
Specifically they re-link the shared library based on the requirements of the
rest of the files in the filesystem.

This linking occurs on the original *.o files that produced the original glibc.
  Internal and external glibc dependencies are fully resolved and the resulting
binary is as-if you built glibc and just #ifdef-ed out a lot of code...  (FYI
there are a few implicit glibc dependencies that have to be known by the tool
itself as they can't be gleamed from objdump.)

The key with this type of optimization though is that it is very specific to a
given filesystem.  Don't expect to add large chunks of functionality to an
existing filesystem, without first having to re-link glibc for any pieces that
may be missing.

As far as the libnss stuff goes, in reality it's rarely an issue for the systems
that need this type of optimization.  They don't have a true users/groups setup,
nor usually have internet connectivity (requiring DNS).  (At least that has been
my experience.)

So short answer, running a glibc "optimizer" which re-links the original glibc
.o files is absolutly safe and supportable.. you just have to understand what it
means and how it works to decide if it is right for your application.

--Mark
(Just as a note, I speak for myself and not my company when I write to these
lists... unless I specifically claim to be speaking for MontaVista)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: glibc vs. newlib

[Mark Hatle]

Steven Scholz wrote:
> Mark Hatle wrote:
>
>> ... So short answer, running a glibc "optimizer" which re-links the
>> original glibc
>> .o files is absolutly safe and supportable.. you just have to
>> understand what it
>> means and how it works to decide if it is right for your application.
>>
>
> Could you recommend one specific open source glibc "optimizer", please?
>
> Maybe even with a URL... :o)

Sorry I don't have an URL, but the one I know of at the top of my head is part
of Debian.  They use it to shrink the size of glibc for their install disks.
Check out "freshmeat.net", I know there are more then one of them out there.

--Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/