This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unexpected presence of __eprintf in libgcc.a when using newlib


On Tue, Apr 8, 2014 at 8:19 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Apr 8, 2014 at 8:14 PM, Thomas Preud'homme
> <thomas.preudhomme@arm.com> wrote:
>>> From: Ian Lance Taylor [mailto:iant@google.com]
>>>
>>> I don't think anything uses __eprintf any more.  The function has been
>>> left behind for very very very old systems.  Actually we could
>>> probably remove it now.  Probably the old support for not building
>>> __eprintf when --with-newlib was specified has bitrotted.
>>
>> Removing it would be great. I'm working on a patch to automatically pull support
>> for floating point in printf/scanf and having eprintf in libgcc lead to such support
>> to be always pulled in since it calls printf and the format used is not a string litteral.
>
> I think your patch is broken since the object file (_eprintf.o) should
> not be pulled in unless it is used and it is part of an archive and
> for archives cause the linker to only bring in object files which have
> things referenced to them.

Also the comment in libgcc2.c is very clear of why it is still around:
/* __eprintf used to be used by GCC's private version of <assert.h>.
   We no longer provide that header, but this routine remains in libgcc.a
   for binary backward compatibility.  Note that it is not included in
   the shared version of libgcc.  */

Thanks,
Andrew Pinski


>
> Thanks,
> Andrew Pinski
>
>>
>> Should I propose a patch to remove it?
>>
>> Best regards,
>>
>> Thomas
>>
>>
>>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]