On Tue, 30 Oct 2007, Bruno Haible wrote:
Tim Rice wrote:
The build fails on Caldera OpenLinux 3.1.1
Here is a snipet of the build log
make all-am
make[2]: Entering directory `/usr/local/src/gnu/m4-1.3.10/lib'
source='/opt/src/gnu/m4-1.4.10/lib/gl_array_list.c'
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
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.
-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
-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).
are
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
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. Can't
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,
but the
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 (sizeof
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 (sizeof
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:
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 configured
* 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
13 matches
Mail list logo
