configure patch for hpux

configure patch for hpux

[law]

aclocal.m4 includes code to find what options (if any) will put the host
compiler into an ANSI-like mode.

However, we do not want to go into strict ANSI mode as that turns off
useful extensions and breaks some systems's header files (almost a direct
quote from aclocal.m4).

For HPUX, using -Aa gives you an ANSI compiler, but has non-ANSI extensions
turned off.  -Ae gives you ANSI with the extensions.

Amazingly enough, this actually matters as I've personally experienced on
an hpux10.20 system with the unbundled ANSI compiler installed.

This patch to aclocal.m4 uses -Ae instead of -Aa to get ANSI+extensions
on hpux systems.

I have checked that this patch does not cause any problems on both
hpux10.20 and hpux11.00 systems, with both the bundled and unbundled
compiler.  It does fix compile-time failures when building with the 
unbundled compiler on hpux10.20.

Some time ago I stepped down as PA maintainer for GDB; so I'm not going
to install the patch until I get authorization from the GDB maintainers.

	* aclocal.m4 (proc_cc_stdc): Use -Ae, not -Aa to get ANSI+extensions
	on hpux systems.
	* configure: Rebuilt.

Index: aclocal.m4
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/aclocal.m4,v
retrieving revision 2.31
diff -c -3 -p -r2.31 aclocal.m4
*** aclocal.m4	2001/08/29 04:06:55	2.31
--- aclocal.m4	2001/12/13 05:29:22
*************** ac_save_CC="$CC"
*** 966,974 ****
  # breaks some systems' header files.
  # AIX			-qlanglvl=ansi
  # Ultrix and OSF/1	-std1
! # HP-UX			-Aa -D_HPUX_SOURCE
  # SVR4			-Xc -D__EXTENSIONS__
! for ac_arg in "" -qlanglvl=ansi -std1 "-Aa -D_HPUX_SOURCE" "-Xc 
-D__EXTENSIONS__"
  do
    CC="$ac_save_CC $ac_arg"
    AC_TRY_COMPILE(
--- 966,974 ----
  # 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(

Re: configure patch for hpux

[Alexandre Oliva]

On Dec 13, 2001, law@redhat.com wrote:

> 	* aclocal.m4 (proc_cc_stdc): Use -Ae, not -Aa to get ANSI+extensions
> 	on hpux systems.

You don't want to modify aclocal.m4, it's a generated file.
It's acinclude.m4 that should get a copy of this macro, that comes
straight from automake, and then have the macro modified.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: configure patch for hpux

[law]

> On Dec 13, 2001, law@redhat.com wrote:
> 
> > 	* aclocal.m4 (proc_cc_stdc): Use -Ae, not -Aa to get ANSI+extensions
> > 	on hpux systems.
> 
> You don't want to modify aclocal.m4, it's a generated file.
> It's acinclude.m4 that should get a copy of this macro, that comes
> straight from automake, and then have the macro modified.
Ugh.  What a pain.  But OK.  I already have an example to work with
(from make-3.79, which does the same thing).

jeff

Re: configure patch for hpux

[Alexandre Oliva]

On Dec 13, 2001, law@redhat.com wrote:

> Ugh.  What a pain.  But OK.  I already have an example to work with
> (from make-3.79, which does the same thing).

Just copy the macro from aclocal.m4 to acinclude.m4 and apply the
change there.  From then on, running `aclocal' will pick the macro
from acinclude.m4, instead of from automake's macro library.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: configure patch for hpux

[Andrew Cagney]

> On Dec 13, 2001, law@redhat.com wrote:
> 
> 
>> Ugh.  What a pain.  But OK.  I already have an example to work with
>> (from make-3.79, which does the same thing).
> 
> 
> Just copy the macro from aclocal.m4 to acinclude.m4 and apply the
> change there.  From then on, running `aclocal' will pick the macro
> from acinclude.m4, instead of from automake's macro library.


Alexandre, two questions.
Would this -Ae vs -Aa going to be accepted into the master sources.
If it isn't, should GDB change the name so that there isn't any confusion?

Andrew

Re: configure patch for hpux

[Alexandre Oliva]

On Dec 15, 2001, Andrew Cagney <ac131313@cygnus.com> wrote:

> Would this -Ae vs -Aa going to be accepted into the master sources.

AFAIK, they're already fixed in the master sources, in the sense that
autoconf 2.5x has a macro that replaces that in automake with the
right semantics.  But I don't know for sure, I haven't looked at
autoconf and automake for a while (6 months or so :-(

> If it isn't, should GDB change the name so that there isn't any confusion?

Renaming the macro is a good idea.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: configure patch for hpux

[law]

  > Just copy the macro from aclocal.m4 to acinclude.m4 and apply the
  > change there.  From then on, running `aclocal' will pick the macro
  > from acinclude.m4, instead of from automake's macro library.
BTW, who maintains automake these days?  This problem really should be
fixed in automake itself.  We really don't want to be putting compilers
into strict ANSI mode -- automake even has a comment to this effect, but
whomever wrote the code apparently wasn't aware of how to get the desired
behavior out of the HP-UX compiler.

jeff

Re: configure patch for hpux

[Tom Tromey]

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

Jeff> BTW, who maintains automake these days?  This problem really
Jeff> should be fixed in automake itself.  We really don't want to be
Jeff> putting compilers into strict ANSI mode -- automake even has a
Jeff> comment to this effect, but whomever wrote the code apparently
Jeff> wasn't aware of how to get the desired behavior out of the HP-UX
Jeff> compiler.

Technically I maintain it.  In practice Akim Demaille does.

The current automake/m4/ccstdc.m4 says this:

    # HP-UX 10.20 and later	-Ae
    # HP-UX older versions	-Aa -D_HPUX_SOURCE

It would be good to upgrade our tree to automake 1.5.
However, 1.5 might not yet be stable enough for this :-(.

Tom

Re: configure patch for hpux

[Andrew Cagney]

> Amazingly enough, this actually matters as I've personally experienced on
> an hpux10.20 system with the unbundled ANSI compiler installed.


Jeff, can you elaborate here

	Andrew

Re: configure patch for hpux

[law]

  > Technically I maintain it.  In practice Akim Demaille does.
  >
  > The current automake/m4/ccstdc.m4 says this:
  >
  >    # HP-UX 10.20 and later	-Ae
  >    # HP-UX older versions	-Aa -D_HPUX_SOURCE
Yea, that wouldn't surprise me.   I seem to recall that -Ae is a relatively
new switch (circa 1996/1997).

So, maybe the right thing to do (if we still care about anything pre-hpux10.20)
is to try -Ae first, then fall back to -Aa -D_HPUX_SOURCE.


  > It would be good to upgrade our tree to automake 1.5.
  > However, 1.5 might not yet be stable enough for this :-(.
I'm not really qualified to make that call.

Tom