On Thu, 1 Nov 2007, Bruno Haible wrote:
> Well, then in a normal situation the AC_HEADER_STDBOOL macro should not
> have set HAVE__BOOL to 1.
>
> I guess you have either the CONFIG_SITE variable set, or a config.site file
> somewhere, or passed a --config-cache option to configure, or you configu
> * Paul Eggert <[EMAIL PROTECTED]> [2007-10-31 16:47:06 -0700]:
>
> Sam Steingold <[EMAIL PROTECTED]> writes:
>
>> incidentally, why isn't ac_use_included_regex cached?
>
> Typically we don't cache things that can be computed cheaply. Can't
> it be computed cheaply, assuming gl_cv_func_re_compile
Hello,
Tim Rice wrote:
> > Can you please try two more snippets?
> >
> > == snippet3.c
> > typedef _Bool ac__type_new_;
> > int
> > main ()
> > {
> > if ((ac__type_new_ *) 0)
> > return 0;
> > if
Hi Jim,
Peter O'Gorman wrote:
> checking for working mktime... yes
> checking for SVID conformant putenv... no
> checking for working strtod... yes
Good. This means that only 'putenv' and possibly 'realpath' are affected.
Jim, here is a proposed patch to the 'putenv' module. Apart from changing
On Thu, 1 Nov 2007, Bruno Haible wrote:
> Can you please try two more snippets?
>
> == snippet3.c
> typedef _Bool ac__type_new_;
> int
> main ()
> {
> if ((ac__type_new_ *) 0)
> return 0;
> if (si
Tim Rice wrote:
> > - the brand and version of cc ?
> $ gcc --version
> 2.95.2
Thanks.
> > - "grep -i bool config.status" ?
> $ grep -i bool config.status
> s,@STDBOOL_H@,|#_!!_#|stdbool.h,g
> s,@HAVE__BOOL@,|#_!!_#|1,g
That's the problem: The autoconf test has determined that _Bool exists,
Sam Steingold <[EMAIL PROTECTED]> writes:
> this is a glibc system and should be using the exact same code.
gnulib regex has a couple of bugs fixed, compared to older glibc.
> incidentally, why isn't ac_use_included_regex cached?
Typically we don't cache things that can be computed cheaply. Ca
Micah Cowan <[EMAIL PROTECTED]> writes:
> If you want to go ahead and continue doing it the way you're doing it,
> you may wish to leave the "restrict" keywords as they appear in the
> original source files, and pass -Drestrict= to g++
This is enough of a hassle in practice that we've fixed the p
Sam Steingold <[EMAIL PROTECTED]> writes:
> it appears that gnulib regex.m4 declares my regex broken:
glibc was broken through 2.5; see the comments in m4/regex.m4.
That probably explains your symptom.
If you'd like more explanation, you can dig through config.log to find
the source code of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sam Steingold wrote:
> it appears that gnulib regex.m4 declares my regex broken:
>
> config.cache:818:gl_cv_func_re_compile_pattern_working=${gl_cv_func_re_compile_pattern_working=no}
>
> this is weird given that the system is an fc5 (glibc 2.4).
> a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
it appears that gnulib regex.m4 declares my regex broken:
config.cache:818:gl_cv_func_re_compile_pattern_working=${gl_cv_func_re_compile_pattern_working=no}
this is weird given that the system is an fc5 (glibc 2.4).
are your sure glibc 2.4 has a brok
The files longlong.m4 and ulonglong.m4 still contain some macros marked
as obsolete. I remove them (also in gettext).
2007-10-31 Bruno Haible <[EMAIL PROTECTED]>
* m4/intmax_t.m4 (gl_AC_TYPE_INTMAX_T, gt_AC_TYPE_INTMAX_T): Use
AC_TYPE_LONG_LONG_INT instead of gl_AC_TYPE_LONG_LON
Paul Eggert wrote:
> > 2007-10-26 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * lib/autoconf/types.m4 (_AC_TYPE_LONG_LONG_SNIPPET): New macro,
> > extracted from AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT.
> > (AC_TYPE_LONG_LONG_INT, AC_TYPE_UNSIGNED_LONG_LONG_INT): Use it.
13 matches
Mail list logo
