On 04/07/2011 04:02 AM, Bruno Haible wrote:
> Hi Paul,
>
>> the gnulib code added quite a bit of of unnecessary work
>> to configure and build vasnprintf.o, printf-parse.o, printf-args.o,
>> and asnprintf.o. None of these object files were needed: they were put
>> into libgnu.a but were not used b
On 04/08/2011 03:58 AM, Simon Josefsson wrote:
> Paul Eggert writes:
>
>> But that raises another problem. For Emacs, I'd like a variant of
>> vasnprintf that uses Emacs's allocators rather than malloc/realloc/free.
>> I could instead attack the problem by blocking interrupts while
>> calling va
Paul Eggert writes:
> But that raises another problem. For Emacs, I'd like a variant of
> vasnprintf that uses Emacs's allocators rather than malloc/realloc/free.
> I could instead attack the problem by blocking interrupts while
> calling vasnprintf, but I'd rather not add these extra system cal
On 04/07/2011 03:02 AM, Bruno Haible wrote:
> Maybe if you present
> a complete patch for the vasnprintf case, it will show in the daylight how
> gnulib-tool should perform this extended dependency tracking?
Thanks for your comments. I'll think about this, but in the meantime
I've discovered that
Hi Paul,
> the gnulib code added quite a bit of of unnecessary work
> to configure and build vasnprintf.o, printf-parse.o, printf-args.o,
> and asnprintf.o. None of these object files were needed: they were put
> into libgnu.a but were not used by anybody.
Additionally, when a shared library is b
I recently modified a test version of Emacs to use gnulib's vsnprintf
module, and found that on my RHEL 5.6 host (which has a working
vsnprintf), the gnulib code added quite a bit of of unnecessary work
to configure and build vasnprintf.o, printf-parse.o, printf-args.o,
and asnprintf.o. None of the
