RE: selective linking of floating point support for *printf / *scanf

["Thomas Preud'homme" <thomas dot preudhomme at arm dot com>]

> From: Joern Rennecke [mailto:joern.rennecke@embecosm.com]
> Sent: Tuesday, August 26, 2014 6:44 PM
> 
> Due to the library order defined in the specs, the float-enbled printf
> definition will
> be picked up from libprintf_flt.a .

It seems to me that it relies heavily on how symbol resolution works. If
I understand correctly all undefined symbols (for instance __int_printf)
in object files are processed first. Symbols definition are search in the
order in which libraries are given in the command line (this part seems
pretty reliable since it's at least documented in ld's manual). When
doing so, if a symbol definition reference an undefined symbol (like
__int_printf referencing printf), it is left aside until all undefined
symbol from object files have been processed. At some point printf
from object file will be processed and will pull the printf with float
support since it's the first one encountered. Then the undefined
reference discovered when pulling symbols from library will be
processed and since printf with float was already pulled in that's
the one being used.

Is this behavior the same for all linker? It sounds like a reasonable
algorithm but I don't know well the variety of linkers out there.

> That testcase is not valid. You'd to use one of the v*printf functions.
> Solving the general problem for these is not computable; for specific cases, it
> would be possible, but at the cost of varying degrees of complexity.
> So I let this for manual selection: it's not handled with the
> calls.stdio_altname
> hook, and you have to use a special link line to use the integer-only
> implementations.
> Well, if desired, a spec change could give an option to do that.

Right, my bad, no problem indeed. What "general problem" are you
referring too that is not solved with this patch?

> 
> That can be implemented with suitable *newlib*.[ch] files that are
> selected in config.gcc,
> akin to newlib-stdint.h and glibc-c.c .

Absolutely, that was the approach I followed in my own patch.

> 
> Well, all the *printf functions are variadic, and as stated above,
> your example is invalid.
> The wildcard are va_list taking functions.  You first have to decide
> what you want to
> happen with these by default, and what kind of non-default behaviour
> you'd like to be
> able to select, and how; than we can talk about if this neeeds any
> extra infrastructure
> to implement.

Yes my apologize, it was a mistake from me.

I'll now do a more thorough testing and report back to you how it works for
us.

Best regards,

Thomas