On 10/24/2012 01:07 PM, Adrian Bunk wrote:
> You also have to exclude AC_PROG_CC_C89 and AC_PROG_CC_C99 (similar
> to AC_PROG_CC_STDC) in au_exclude_list in tests/mktests.sh to fix the
> "make check" errors this causes.
Thanks, I just now pushed
o this is an Autoconf bug. I installed this into Autoconf:
>...
You also have to exclude AC_PROG_CC_C89 and AC_PROG_CC_C99 (similar
to AC_PROG_CC_STDC) in au_exclude_list in tests/mktests.sh to fix the
"make check" errors this causes.
cu
Adrian
--
"Is there not promise o
17 00:00:00 2001
From: Paul Eggert
Date: Wed, 24 Oct 2012 12:25:34 -0700
Subject: [PATCH] AC_PROG_CC_C89, AC_PROG_CC_C99, AC_PROG_CC_STDC: Use
AU_DEFUN
This fixes a bug introduced by the most recent change to c.m4.
Problem reported by Jim Meyering in
<http://lists.gnu.org/archive/html/autocon
When attempting to bootstrap grep.git using
autoconf.git (v2.69-37-gb9dc6b6), I see this failure:
autoreconf: running: aclocal -I m4 -I m4
configure.ac:81: error: AC_PROG_CC cannot be called after AM_PROG_CC_C_O
../../lib/autoconf/c.m4:1459: AC_PROG_CC_STDC is expanded from...
m4
On Wed, Mar 27, 2002 at 09:00:10PM -0500, Peter Eisentraut wrote:
> # AIX -qlanglvl=ansi
> # Ultrix and OSF/1 -std1
> # HP-UX 10.20 and later -Ae
> # HP-UX older versions -Aa -D_HPUX_SOURCE
> # SVR4 -Xc -D__EXTENSIONS__
>
> where -qlanglvl=ansi and -std1 s
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> Date: Wed, 27 Mar 2002 21:00:10 -0500 (EST)
> Code that tries to be portable to K&R uses some restricted subset of C
> that is portable both ways, so it wouldn't break if we ran it through an
> ANSI C compiler.
That's how things used to be, but thes
Paul Eggert writes:
> > I've been thinking lately about the issues surrounding this macro (see
> > archives and TODO list). Is there any reason why AC_PROG_CC_STDC could
> > not simply be folded into AC_PROG_CC? Is there any software that must
> > avoid an ANSI
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> Date: Wed, 27 Mar 2002 16:59:10 -0500 (EST)
>
> I've been thinking lately about the issues surrounding this macro (see
> archives and TODO list). Is there any reason why AC_PROG_CC_STDC could
> not simply be folded i
I've been thinking lately about the issues surrounding this macro (see
archives and TODO list). Is there any reason why AC_PROG_CC_STDC could
not simply be folded into AC_PROG_CC? Is there any software that must
avoid an ANSI C compiler at all cost? That kind of software would hard
I noticed AC_C_STRINGIZE doesn't force itself to be after
AC_PROG_CC_STDC, and I think this can lead to wrong results when "cc
-E" is used for preprocessing and AC_PROG_CC_STDC mungs $CC into ansi
mode, if something like the following is accidentally written.
It seems like it would be logical to have AC_PROG_CC always run before
AC_PROG_CPP (since this turns out to be `$CC -E' in lots of cases).
In aclang.m4, there is:
dnl FIXME: can't do this because then AC_AIX won't work due to a
dnl circular dependency.
dnl AC_BEFORE([$0], [AC_PROG_CPP])
Why is
n some systems `cc' is a K&R compiler and the ANSI compiler is
`c89'. In that case the configure script
AC_PROG_CC
AC_PROG_CC_STDC
would first decide on `cc' as the compiler and then fail to switch it to
ANSI mode, never considering `c89'. (The obvious solution would be
Johan Danielsson writes:
> This of course depends on what the CC_STDC macro means,
It effectively tries to give a couple of flags to the compiler to make it
a little more modern. That means accepting prototypes and perhaps const,
etc.
> but if it tests for a `ANSI C' compiler, -std is not enoug
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > I've written about it before, here's the patch. It changes
> > AC_PROG_CC_STDC to try the `-std' flag rather than `-std1' (for OSF
> > or Ultrix) because the latter is kind of like &#
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've written about it before, here's the patch. It changes
> AC_PROG_CC_STDC to try the `-std' flag rather than `-std1' (for OSF
> or Ultrix) because the latter is kind of like 'gcc -ansi' (i.e.,
> ter
On Apr 19, 2000, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> I've written about it before, here's the patch. It changes AC_PROG_CC_STDC
> to try the `-std' flag rather than `-std1' (for OSF or Ultrix) because the
> latter is kind of like 'gcc -ansi'
>
> Peter Eisentraut writes:
> > I've written about it before, here's the patch. It changes AC_PROG_CC_STDC
> > to try the `-std' flag rather than `-std1' (for OSF or Ultrix) because the
> > latter is kind of like 'gcc -ansi' (i.e., termi
Peter Eisentraut writes:
> I've written about it before, here's the patch. It changes AC_PROG_CC_STDC
> to try the `-std' flag rather than `-std1' (for OSF or Ultrix) because the
> latter is kind of like 'gcc -ansi' (i.e., terminally strict).
I've
I've written about it before, here's the patch. It changes AC_PROG_CC_STDC
to try the `-std' flag rather than `-std1' (for OSF or Ultrix) because the
latter is kind of like 'gcc -ansi' (i.e., terminally strict).
Treat with caution, I don't actually have one of
19 matches
Mail list logo
