http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718
--- Comment #11 from Joerg Wunsch <j at uriah dot heep.sax.de> 2011-11-28
19:45:51 UTC ---
(In reply to comment #10)
> Jörg, could you prepare a list of functions that shall be excluded from
> libgcc?
> You can also answer to my mail "PR28718 Infos?" from 2011-11-10.
Well, perhaps. However, the AVR-part is not the main subject of my
complaint here. The subject of my complaint was/is that a call to
*any* library is added *prior* to the list of user-supplied libaries
(from -l options). The point of -l options is to give the users an
override option, which is completely defeated by the current way
libstdc++ is handled.
The fact that the AVR (currently) lacks a libstdc++, and thus libgcc
is linked instead, caused this bug to be escalated due to the side
effects, but this is not the main point here.
This becomes even more puzzling now: apparently, this reordering of
the libraries *only* applies to -lm. When specifying any other
library, the processing works as one would expect it to be.
The code for this is in gcc/cp/g++spec.c, around line 270:
/* Make sure -lstdc++ is before the math library, since libstdc++
itself uses those math routines. */
if (!saw_math && (args[i] & MATHLIB) && library > 0)
{
--j;
saw_math = &decoded_options[i];
}
OK, now the reason is clear. However, this doesn't handle the case
very well where no libstdc++ is available at all: inserting libgcc in
place of libstdc++ is just a simple workaround, and apparently a too
simple one in our case. A correct implementation would not try to add
anything at all when libstdc++ is unavailable (and thus have no need
to reorder).
I don't know how many targets are affected at all by the lack of
libstdc++. If AVR is indeed the only target where this applies to,
then the way you outlined (a configurable list of functions to omit
from libgcc) might be the best compromise.
(Sorry it took me so long to reply, Johan, but I knew it would take me
some time to research all this again, and then create the reply.)
