avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Bugs before 1.2.0


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Bugs before 1.2.0
Date: Thu, 23 Dec 2004 07:21:30 +0100
User-agent: Mutt/1.4.2.1i

As Paul Schlie wrote:

> > Please give a good reason why you think they should remain
> > distinct.  What advantages would there be for keeping them
> > seperate?

> Possibly because they are distinct collections of functions, for
> distinct purposes, which are traditionally presumed to be and
> utilized as such.

So what?

Unices these days usually keep a lot of crap in their libc.a
libraries, much more than what has traditionally been there.  Who
cares?  The linker only picks up what is needed anyway.  Non-Unix
systems often never made a distinction between the C and the math
library at all.

IMHO, the tradition only arised out of the limitations of early Unix
systems, namely space limitations on the PDP-11, remember, an
ATmega128 with external RAM has more combined address space (and far
more compute power) than a PDP-11 ever had.  Unices simply followed
that `tradition' then forever, even though the original reasons
disappeared long before.

> (If you want to merge these distinct libraries into a single
> linkable dead-code-strip-able library, it shouldn't likely be named
> libc, as that's not what C programmers would expect it to contain.)

C programmers are normally not supposed to explicitly specify -lc on
their command lines anyway, as the compiler has always been implicitly
linking against it.  So they won't see a change.

Point is (not sure whether you actually read the bug report at all,
Paul), our standard functionality basically requires that you link
against -lm right now.  Even the C compiler implicitly uses functions
out of it (as libm.a provides some of GCC's internally used
functions), and stuff declared in <stdlib.h> (strtod(), dtostre(),
dtostrf()) is only contained in libm.a (just for that reason that the
actual implementation of all these functions is in FPLIB), which is
confusing at best.  Rather than complicating the Makefile structure
even more than it already is to ensure these functions go to libc.a, I
simply see no point in distinguishing both libs anymore at all.

If you have any really good reason for keeping them distinct (like a
hypothetical example that would break by merging them), I'd like to
here about it.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]