Assar Westerlund wrote:
>Ben Pfaff <[EMAIL PROTECTED]> writes:
>> Either I'm very confused, or it's not possible to use the autoconf
>> tests AC_EXEEXT and AC_MINIX in the same configure.in...
>
>Yes, this is a problem. But in this particular case I would say that
>AC_MINIX should be considered obsolete and not used. What do you use
>AC_MINIX for? Can you just use AC_CHECK_HEADERS and
>AC_CANONICAL_SYSTEM?
I'm just trying to get the bash-2.03 configure.in to work on this
system :-> Since that has AC_MINIX and AC_ISC_POSIX in it, I just
left them in... If those macros are obsolete shouldn't autoconf
be warning about their use, anyway?
[And from a practical point of view there are lots of places in
the code that do things like #ifdef _MINIX; whilst I know I'm not
going to try to build my modified source tree on Minix, I didn't
see the need to gratuitously break it either...]
I could submit bug reports against bash as well, I suppose; it tends
to use
#ifndef _MINIX
#include <sys/file.h>
#endif
where it ought to use HAVE_SYS_FILE_H, plus there's the occasional
complete foul-up like:
#ifdef HAVE_CONFIG_H
#include <config.h>
#else /* not HAVE_CONFIG_H */
#if defined(HAVE_STRING_H) || defined(STDC_HEADERS)
#define bcopy(s, d, n) memcpy ((d), (s), (n))
#endif
#ifdef STDC_HEADERS
#include <stdlib.h>
#include <string.h>
#else
char *malloc ();
char *realloc ();
#endif
#endif /* not HAVE_CONFIG_H */
which results in not including the standard headers if HAVE_CONFIG_H
is set...
[This system *really* hates it if you try to declare your own prototypes
for library functions rather than including the headers -- it will
refuse to link...]
Peter Maydell
