On Fri, 22 Feb 2002, Paul Eggert wrote: > > From: Len Makin <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED]
