Re: [avr-libc-dev] Doc fix: new device support / Bugs before 1.2.0

[Paul Schlie]

> Joerg Wunsch <address@hidden> wrote
>> As Russell Shaw wrote:
>> Why is there doconf/domake instead of just configure/make?
> 
> Because of the way the multilib setup (library generation for the
> avr2, avr3, avr4, and avr5 `architectures') is arranged by now.
> The wrapper scripts simply organize the generation of all four
> sub-libraries.

- actually there's no good reason to preserve them, other than it would seem
the path of least effort to do so (not bad, but reality).

- although it may be worth while taking a peek at newlib's config.in/etc.
definitions, as newlib's config/make infrastructure does construct avr3 ..
avr5 multi-lib build dirs without requiring any ad-hoc doconf/make
helpers.

> Joerg Wunsch <address@hidden> wrote (re: merge of libm into libc):
>                ... 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 would seem to be a strong case to actually appropriately relocate
the functions in question into their correct library, possibly using the
same library partitioning scheme utilized by newlib (which does implement
strtod(), etc. correctly as part of stdlib, not libm).

- again not a real big deal, but if there is any interest in possibly
positioning avr-libc as an asm optimized partial implementation of newlib,
their two implementation directories hierarchies should ideally be as
similar as reasonably possible. (if not, I agree that it really doesn't
matter).