Re: Five bugs (IBM-PC systems)

[Pavel Jan Lastovicka]

Paul Eggert wrote:
> 
> Pavel Jan Lastovicka <address@hidden> writes:
> 
> > 2. the check whether make sets ${MAKE}
> >
> > I have to insert 'SHELL=sh' before 'all:'
> > - a Unix shell is not the default shell on non-Unix systems...
> 
> It might make things easier for you if you set SHELL=sh in your
> environment before futzing with this stuff.  No sense tilting
> at windmills....

Sorry, you are wrong. Of course I have the SHELL env. variable set.
I'm quoting from doc for GNU make 3.75:

      Unlike most variables, the variable `SHELL' is never set from the
   environment.  This is because the `SHELL' environment variable is used
   to specify your personal choice of shell program for interactive use.
   It would be very bad for personal choices like this to affect the
   functioning of makefiles.

Nobody can force people using a port of GNU make to use the Unix shell
- they even need not have any...

> > 4. the check whether $CC accepts -g
> >
> > This check overwrites user's CFLAGS setting which is bad:
> 
> Ugly, but not fatal; it just doesn't use -g.  You can set
> CFLAGS='-Zomfg' if you want -g.

I know. Also once a config.status is produced I can change
compiler/linker flags there as many times as I like.
I haven't posted because of problems (I am quite
accustomed with fixing bugs in open source software...)
but because I wanted to improve autoconf.
(Could you tell why this check for -g ?  For ordinary users
it only slows down the build process and occupies
considerably more disk space.)

> >   configure.:6279: checking for strerror in -lcposix
> 
> Sounds like you have an old Autoconf; I think that bug was fixed in
> <http://mail.gnu.org/archive/html/bug-fileutils/2001-09/msg00037.html>.
> Anyway, that's from AC_ISC_POSIX. I'd just stop using that macro; it's
> obsolescent.

Sorry for posting about an already fixed problem. I don't have autoconf
and so I don't know how to verify a problem.
But in general I dislike the idea that if one downloads a recent GNU package
that he would have to get the latest available autoconf in order to generate
a new configure script that wouldn't contain bugs from autoconf used
when the software was packaged for distribution.

Pavel Lastovicka