Re: [avr-libc-dev] Question on Optimizations with Linking

[Joerg Wunsch]

As Colin O'Flynn wrote:

> Would it be a reasonable idea to change the optimization strategy
> for linking around a bit? Right now for example we already have a
> few options for printf, and now are looking at different options for
> itoa.

It would be possible, but I'm not too happy with that.  Managing
different linker options is sort of a pain in the butt.  This is
particularly true for printf/scanf, where it's the backend functions
vfprintf/vfscanf that decide about the feature set, yet virtually
nobody uses them in their own code.  So currently, you're required to
have one -uvfscanf linker option in your command-line if you want
them, so these respective functions will be pulled in from their
respective libraries.

Hmm, thinking more about it, this could perhaps be changed...  We
could create libraries that contain all parts of the printf or scanf
family, respectively.  I'm not sure about the automake magic involved.

> What I was proposing was a more intelligent linking operation,
> basically moving those options out of the Makefile. Then you have a
> separate file that lists options you want.

We don't want to modify the linker.  I don't necessarily like the idea
of maintaining yet another file though.


As Bernard Fouché wrote:

> ... I would prefer to have access
> to printf_min() printf_float(), etc. and write code this way:

I understand your sentiments.  But keep in mind that there's no such
thing like a printf_min() and a printf_std(), but only a vfprint_min()
and vfprintf_std().  Cloning each and every member to a different name
would be a tedious task (though I don't say it can't be done).

I agree though that having everything as compile-time options would
have been my preference as well.  I only didn't see a good way to have
it done with reasonable effort, that's why I invented the linker
options.

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

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