Update for AC_PROG_STDC_CC fix

Update for AC_PROG_STDC_CC fix

[law]

Per Alex's message, the right thing to do is to put a copy of AM_PROG_CC_STDC
into acinclude.m4, fix it, and run aclocal.m4 to propagage the changes into
aclocal.m4.

Here's the patch to do this.  As with the previous patch, I'll hold off
installing until I hear from one of the gdb maintainers.

	* acinclude.m4 (AM_PROG_CC_STDC): New macro to override the broken
	one in automake.  Uses -Ae, not -Aa to put HP compiler into ANSI
	with extensions mode.
	* aclocal.m4: Rebuilt.

Index: acinclude.m4
===================================================================
RCS file: /cvs/src/src/gdb/acinclude.m4,v
retrieving revision 1.2
diff -c -3 -p -r1.2 acinclude.m4
*** acinclude.m4	2000/09/12 04:23:30	1.2
--- acinclude.m4	2001/12/18 17:44:13
*************** dnl CY_GNU_GETTEXT into aclocal.m4.
*** 866,868 ****
--- 866,954 ----
  ifelse(yes,no,[
  AC_DEFUN([CY_GNU_GETTEXT],)
  ])
+ 
+ # @defmac AC_PROG_CC_STDC
+ # @maindex PROG_CC_STDC
+ # @ovindex CC
+ # If the C compiler in not in ANSI C mode by default, try to add an option
+ # to output variable @code{CC} to make it so.  This macro tries various
+ # options that select ANSI C on some system or another.  It considers the
+ # compiler to be in ANSI C mode if it handles function prototypes correctly.
+ #
+ # If you use this macro, you should check after calling it whether the C
+ # compiler has been set to accept ANSI C; if not, the shell variable
+ # @code{am_cv_prog_cc_stdc} is set to @samp{no}.  If you wrote your source
+ # code in ANSI C, you can make an un-ANSIfied copy of it by using the
+ # program @code{ansi2knr}, which comes with Ghostscript.
+ # @end defmac
+ 
+ AC_DEFUN(AM_PROG_CC_STDC,
+ [AC_REQUIRE([AC_PROG_CC])
+ AC_BEFORE([$0], [AC_C_INLINE])
+ AC_BEFORE([$0], [AC_C_CONST])
+ dnl Force this before AC_PROG_CPP.  Some cpp's, eg on HPUX, require
+ dnl a magic option to avoid problems with ANSI preprocessor commands
+ dnl like #elif.
+ 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])
+ AC_MSG_CHECKING(for ${CC-cc} option to accept ANSI C)
+ AC_CACHE_VAL(am_cv_prog_cc_stdc,
+ [am_cv_prog_cc_stdc=no
+ ac_save_CC="$CC"
+ # Don't try gcc -ansi; that turns off useful extensions and
+ # breaks some systems' header files.
+ # AIX			-qlanglvl=ansi
+ # Ultrix and OSF/1	-std1
+ # HP-UX			-Ae -D_HPUX_SOURCE
+ # SVR4			-Xc -D__EXTENSIONS__
+ for ac_arg in "" -qlanglvl=ansi -std1 "-Ae -D_HPUX_SOURCE" "-Xc -D__EXTENSIONS__"
+ do
+   CC="$ac_save_CC $ac_arg"
+   AC_TRY_COMPILE(
+ [#include <stdarg.h>
+ #include <stdio.h>
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
+ struct buf { int x; };
+ FILE * (*rcsopen) (struct buf *, struct stat *, int);
+ static char *e (p, i)
+      char **p;
+      int i;
+ {
+   return p[i];
+ }
+ static char *f (char * (*g) (char **, int), char **p, ...)
+ {
+   char *s;
+   va_list v;
+   va_start (v,p);
+   s = g (p, va_arg (v,int));
+   va_end (v);
+   return s;
+ }
+ int test (int i, double x);
+ struct s1 {int (*f) (int a);};
+ struct s2 {int (*f) (double a);};
+ int pairnames (int, char **, FILE *(*)(struct buf *, struct stat *, int), int, int);
+ int argc;
+ char **argv;
+ ], [
+ return f (e, argv, 0) != argv[0]  ||  f (e, argv, 1) != argv[1];
+ ],
+ [am_cv_prog_cc_stdc="$ac_arg"; break])
+ done
+ CC="$ac_save_CC"
+ ])
+ if test -z "$am_cv_prog_cc_stdc"; then
+   AC_MSG_RESULT([none needed])
+ else
+   AC_MSG_RESULT($am_cv_prog_cc_stdc)
+ fi
+ case "x$am_cv_prog_cc_stdc" in
+   x|xno) ;;
+   *) CC="$CC $am_cv_prog_cc_stdc" ;;
+ esac
+ ])
+ 

Re: Update for AC_PROG_STDC_CC fix

[Andrew Cagney]

>  * acinclude.m4 (AM_PROG_CC_STDC): New macro to override the broken
> 	one in automake.  Uses -Ae, not -Aa to put HP compiler into ANSI
> 	with extensions mode.
> 	* aclocal.m4: Rebuilt.
> 


Mostly ok.  Before checking it in can you please tweek the name to be 
something else (GDB_PROG_CC_STDC?) and modify the description to mention 
how it is different to AM_PROG_CC_STDC.

Are you able to pull this into the 5.1 branch or do you want me to?

Andrew

Re: Update for AC_PROG_STDC_CC fix

[law]

  > >  * acinclude.m4 (AM_PROG_CC_STDC): New macro to override the broken
  > > 	one in automake.  Uses -Ae, not -Aa to put HP compiler into ANSI
  > > 	with extensions mode.
  > > 	* aclocal.m4: Rebuilt.
  > > 
  > 
  > 
  > Mostly ok.  Before checking it in can you please tweek the name to be 
  > something else (GDB_PROG_CC_STDC?) and modify the description to mention 
  > how it is different to AM_PROG_CC_STDC.
Or better yet, can we get rid of it completely from GDB?   The only reason
this causes problems is the bogus definition of prog_cc_stdc found when
configuring gdb bleeds into other directories which use prog_cc_stdc
via a shared config.cache.

I haven't followed things closely enough to know if that's viable or not
(not to mention my lack of knowledge regarding autoconf/automake).

  > Are you able to pull this into the 5.1 branch or do you want me to?
I can if we in fact do need a CC_STDC definition for gdb.

jeff

Re: Update for AC_PROG_STDC_CC fix

[Andrew Cagney]

>  > > * acinclude.m4 (AM_PROG_CC_STDC): New macro to override the broken
>   > > one in automake.  Uses -Ae, not -Aa to put HP compiler into ANSI
>   > > with extensions mode.
>   > > * aclocal.m4: Rebuilt.
>   > > > > > Mostly ok.  Before checking it in can you please tweek the name to be 
>   > something else (GDB_PROG_CC_STDC?) and modify the description to mention 
>   > how it is different to AM_PROG_CC_STDC.
> Or better yet, can we get rid of it completely from GDB?   The only reason
> this causes problems is the bogus definition of prog_cc_stdc found when
> configuring gdb bleeds into other directories which use prog_cc_stdc
> via a shared config.cache.


Isn't something needed for HP/UX to get the compiler into the right 
mode?  But yes I agree, even after renaming the macro, there is a 
problem with prog_cc_stdc clashes.


> I haven't followed things closely enough to know if that's viable or not
> (not to mention my lack of knowledge regarding autoconf/automake).


Ditto.  Tom?


>   > Are you able to pull this into the 5.1 branch or do you want me to?
> I can if we in fact do need a CC_STDC definition for gdb.



Andrew

Re: Update for AC_PROG_STDC_CC fix

[law]

  > Isn't something needed for HP/UX to get the compiler into the right 
  > mode?  But yes I agree, even after renaming the macro, there is a 
  > problem with prog_cc_stdc clashes.
True, that would be a problem.  I wouldn't have mentioned the idea of
zapping AM_PROG_CC_STDC except for the fact that I couldn't figure out
if/how it would ever be used.

It seems to me like the various Makefiles associated with gdb use CC,
but I couldn't find the mechanism by which CC was assigned the result
of AM_PROG_CC_STDC.  But apparently by some magic it does happen.

This in turn begs the question -- if we rename AM_PROG_CC_STDC to
GDB_PROG_CC_STDC will the value computed by GDB_PROG_CC_STDC still
be used to initialize CC in the generated Makefile?

I can try some experiments, but it would really be better if someone
who understands autoconf/automake better could give me some insight
into what unintended consequences we might have due to the name change.

jeff

Re: Update for AC_PROG_STDC_CC fix

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

>> Or better yet, can we get rid of it completely from GDB?   The only reason
>> this causes problems is the bogus definition of prog_cc_stdc found when
>> configuring gdb bleeds into other directories which use prog_cc_stdc
>> via a shared config.cache.

Andrew> Isn't something needed for HP/UX to get the compiler into the right 
Andrew> mode?  But yes I agree, even after renaming the macro, there is a 
Andrew> problem with prog_cc_stdc clashes.

I think clashes should only be a problem if you are using different
versions of this macro in different directories.  If so, that's a
no-no.  It has always been the case that all configure scripts in a
given project must agree about how to compute cache values.  I think
this is an undocumented requirement :-(, but careful examination of
the ChangeLogs will show bug fixes for problems like this dating back
at least to 1996.

HTH,
Tom

Re: Update for AC_PROG_STDC_CC fix

[law]

  > I think clashes should only be a problem if you are using different
  > versions of this macro in different directories.  If so, that's a
  > no-no.  It has always been the case that all configure scripts in a
  > given project must agree about how to compute cache values.  I think
  > this is an undocumented requirement :-(, but careful examination of
  > the ChangeLogs will show bug fixes for problems like this dating back
  > at least to 1996.
Right.  Which is precisely why I'm in this situation to begin with --
"make" has its own version, which was wrong, but at least was closer
to being correct.

After fixing the version in the "make" subdir I was surprised to find
that my fix didn't work.  Which led me to gdb and the shared cache problems...
And through the discussion we find out that anyone using the one directly
from autoconf-1.4 is getting a broken version.

Until autoconf-1.5 is released we probably should be overriding the default
version.  The only question in my mind is how best to do that.  Do we
keep the original name, or do we use a new one?  What affect (if any) does
changing the name have on the magic which uses the result of PROG_CC_STDC
to initialize CC in the generated Makefile?

jeff

Re: Update for AC_PROG_STDC_CC fix

[Tom Tromey]

>>>>> "Jeff" == law  <law@redhat.com> writes:

Jeff> It seems to me like the various Makefiles associated with gdb use CC,
Jeff> but I couldn't find the mechanism by which CC was assigned the result
Jeff> of AM_PROG_CC_STDC.  But apparently by some magic it does happen.

It happens at the end of AM_PROG_CC_STDC:

    case "x$am_cv_prog_cc_stdc" in
      x|xno) ;;
      *) CC="$CC $am_cv_prog_cc_stdc" ;;
    esac

Jeff> This in turn begs the question -- if we rename AM_PROG_CC_STDC
Jeff> to GDB_PROG_CC_STDC will the value computed by GDB_PROG_CC_STDC
Jeff> still be used to initialize CC in the generated Makefile?

Yes.  You also have to rename the cache variables.
It is probably a bit better to just make sure all the directories in
gdb use the same AM_PROG_CC_STDC macro -- use the newest one.
If you do this then it seems to me that it will be a little easier to
pick up future bug fixes.

Tom