* Joel E. Denny wrote on Sat, Nov 20, 2010 at 05:27:08AM CET:
> Thanks to everyone for the input. How about the following patch? I
> foresee two minor issues:
>
> 1. If someone does "bash bootstrap", I'm not sure how to detect that in
> order to do it again in the exec.
Yep, sounds like a pro
From: Khem Raj
uclibc defines __GLIBC__ but it does not expose struct shed_param as
much as glibc and is not needed too per standard. gnulib attempts to
use it but we have to account for it because in this case uclibc does
not behave like glibc.
Signed-off-by: Khem Raj
Signed-off-by: Mike Frys
Hi,
On Wed, 17 Nov 2010, Ralf Wildenhues wrote:
> * Paolo Bonzini wrote on Wed, Nov 17, 2010 at 01:22:25PM CET:
> > On 11/15/2010 11:06 PM, Ralf Wildenhues wrote:
> > >What might work is have bootstrap exec a temporary script that updates
> > >bootstrap then exec's that again.
> >
> > Something
On Friday, November 19, 2010 19:36:12 Ralf Wildenhues wrote:
> * Mike Frysinger wrote on Sat, Nov 20, 2010 at 01:31:13AM CET:
> > that isnt quite the case here. when i do `make clean`, lib/stdint.h does
> > get removed. but the `make` still does GEN on stdint.h even after the
> > re- configure wi
* Mike Frysinger wrote on Sat, Nov 20, 2010 at 01:31:13AM CET:
> that isnt quite the case here. when i do `make clean`, lib/stdint.h does get
> removed. but the `make` still does GEN on stdint.h even after the re-
> configure with the new target.
That's because some .deps/*.Po files still refer
On Friday, November 19, 2010 18:36:40 Eric Blake wrote:
> On 11/19/2010 04:15 PM, Mike Frysinger wrote:
> > On Friday, November 19, 2010 11:46:23 Paul Eggert wrote:
> >> On 11/18/2010 10:48 PM, Mike Frysinger wrote:
> >>> this is because m4/stdint.m4 only defines HAVE_SYS_INTTYPES_H when
> >>> gl_c
On 11/19/2010 04:15 PM, Mike Frysinger wrote:
> On Friday, November 19, 2010 11:46:23 Paul Eggert wrote:
>> On 11/18/2010 10:48 PM, Mike Frysinger wrote:
>>> this is because m4/stdint.m4 only defines HAVE_SYS_INTTYPES_H when
>>> gl_cv_header_working_stdint_h is "no" and i my case, it's yes.
>>
>> S
On 11/19/10 04:40, Bruno Haible wrote:
> You would have to add a line
> gl_MODULE_INDICATOR([snprintf])
> to the snprintf module, and then test
>#if HAVE_SNPRINTF || GNULIB_SNPRINTF
Could we do that with gl_MODULE_INDICATOR([snprintf-posix]) and
the snprintf-posix module instead?
> the maj
On Friday, November 19, 2010 11:46:23 Paul Eggert wrote:
> On 11/18/2010 10:48 PM, Mike Frysinger wrote:
> > this is because m4/stdint.m4 only defines HAVE_SYS_INTTYPES_H when
> > gl_cv_header_working_stdint_h is "no" and i my case, it's yes.
>
> Sorry, I'm lost. If gl_cv_header_working_stdint_h
On 11/18/2010 10:48 PM, Mike Frysinger wrote:
> this is because m4/stdint.m4 only defines HAVE_SYS_INTTYPES_H when
> gl_cv_header_working_stdint_h is "no" and i my case, it's yes.
Sorry, I'm lost. If gl_cv_header_working_stdint_h is "yes"
then why is gnulib stdint.h being used at all?
Is this a
Without this, I'd get failures in coreutils' "make check":
test-rename.c: In function 'test_rename':
test-rename.c:43:1: error: 'main' is normally a non-static function [-Wmain]
test-rename.c:49:1: error: expected declaration or statement at end of input
>From db37bb3e918ce69fd0bf5e45752ed
Hi Paul,
> * lib/ftoastr.c: Also mention Loitsch's draft.
Thanks.
> * lib/ftoastr.h: Require WIDTH to be nonnegative. This isn't
> needed in the current implementation, but it might simplify
> speeding up the code later.
It also avoids the bug with '-' flag and negative width on HP-UX 10.20.
12 matches
Mail list logo