Re: Two problems for autoconf(1.NEC SX 2.Cray)

[Jeroen van den Muyzenberg]

On Fri, 22 Feb 2002, Paul Eggert wrote:

> > From: Len Makin <address@hidden>
> > Date: Fri, 22 Feb 2002 15:31:26 +1100
> >
> >   Len> The compiler cc has a valid debugging option -g, but configure
> >   Len> (autoconf/aclocal macro?) compile test sees the warning:
> >   Len> cc: warning: -g overrides '-h 1','-h vector'
> >   Len> and concludes
> >   [..]
> >   Len> checking whether cc accepts -g... no
>
> In this case it appears to me that configure is doing the right thing.
> If -g changes the semantics of the compiler, then a default build should
> not use -g.

Do we have definition of semantics yet?

The use of -g to a compiler is often the only "first clue" to porting an
app to a "non-standard" architecture. If possible it shouldn't be thwarted
at the autoconf stage.

>
> > Some non GNU software correctly does a test of the exit status of the 
> > command
> > rather than testing for non-null output, and comes to the correct conclusion
> > (for our machine;-).checking whether cc accepts -g... yes....
> > Should meld this into AC_PROG_CC. But is this a robust test
> > for other compilers? YMMV.
>
> Unfortunately not.  Some brain damaged compilers return an exit status
> of zero even when the compilation has failed.  (Also, some installers
> complain when they get a lot of silly compiler warnings like the one
> mentioned above.  :-)

Seems to me that there has been a great deal of effort into dealing with
"brain-damaged" compilers. Why stop now?

>
> > there is no environment variable specification allowed for sed.
>
> Yes there is: you can set PATH so that the 'sed' you want is first in
> the path.

This suggestion is not viable, changing PATH will also remove references
to too many other utilities.

Cheers,
Jeroen

Jeroen van den Muyzenberg
CSIRO Mathematical and Information Sciences
CSIRO/Bureau of Meteorology -
High Performance Computing and Communications Centre
Ph: +61 3 9669 8111 Fax: +61 3 9669 8112
address@hidden